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(57) ABSTRACT 

Provided is a method and mechanism for automating updat- 
ing of computer programs. Conventionally, computer pro- 
grams have been distributed on a recording medium for 
users to install on their computer systems. Each time fixes, 
additions and new versions for the programs were 
developed, a new CD or diskette was required to be deliv- 
ered to users to enable them to install the update. More 
recently some software has been downloadable across a 
network, but the effort for users obtaining and installing 
updates and the effort for software vendors to distribute 
updates remains undesirable. The invention provides an 
updater agent which is associated with a computer program 
and which accesses relevant network locations and auto- 
matically downloads and installs any available updates to its 
associated program if those updates satisfy predefined 
update criteria of the updater agent. The updater agents are 
able to communicate with each other and so a first updater 
agent can request updates to programs which are prerequi- 
sites to its associated program. 

9 Claims, 5 Drawing Sheets 
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DISTRIBUTION OF SOFTWARE UPDATES 
VIA A COMPUTER NETWORK 

FIELD OF INVENTION 

The present invention relates to distribution of software 
via a computer network and to a mechanism for accessing 
software enhancements, corrections or new versions via a 
computer network. A Network' of computers can be any 
number of computers that are able to exchange information 
with one another, and may be arranged in any configuration 
and using any manner of connection. 

BACKGROUND 

Software has conventionally been distributed in the form 
of programs recorded on a recording medium such as a 
diskette or compact disk. Customers buy the recording 
medium and a licence to use the software recorded on the 
medium, and then install the software onto their computers 
from the recording medium. The manufacture and distribu- 
tion of the pre-recorded recording media are expensive, and 
this cost will be passed on to the customer. Also, the effort 
for customers of ordering or shopping for the software is 
undesirable. 

The distribution cost is particularly problematic because 
most software products are frequently updated, both to 
correct bugs and to add new features, after the software has 
been delivered to the user Some types of software products 
are updated many times each year The cost of sending a new 
diskette or CD to all registered customers every time the 
software is upgraded or corrected is prohibitive and, 
although many customers want their software to be the most 
up-to-date, highest performance version and to be error free, 
not all customers want to receive every update. For example, 
the vendor may charge more for updates than the customer 
wants to spend, or new versions may require upgrading of 
other pre-requisite software products which the customer 
does not want to buy, or migrating to new versions may 
require migration of data which would disable the custom- 
er's system for a period of time. 

Thus, software vendors tend to publicise the availability 
of new versions of their software and leave it for the 
customer to decide whether to purchase the latest upgraded 
version. For some software products, however, it is appro- 
priate for the software vendor to proactively send out 
upgraded versions, or at least error correction and enhance- 
ment code (known as "patches") for their software products. 
Whatever a particular company's policy, significant costs 
and effort are involved in releasing these various types of 
software updates. 

Increasingly, software distributors are using the Internet 
as a mechanism for publicising the availability of updates to 
their software, and even for distributing some software. The 
Internet is a network of computer networks having no single 
owner or controller and including large and small, public 
and private networks, and in which any connected computer 
running Internet Protocol software is, subject to security 
controls, capable of exchanging information with any other 
computer which is also connected to the Internet. This 
composite collection of networks which have agreed to 
connect to one another relies on no single transmission 
medium (for example, bidirectional communication can 
occur via satellite links, fiber-optic trunk lines, telephone 
lines, cable television wires and local radio links). 

The World Wide Web Internet service (hereafter 'the 
Web') is a wide area information retrieval facility which 
provides access to an enormous quantity of network- 
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accessible information and which can provide low cost 
communications between Internet-connected computers. It 
is known for software vendors, customers who have Internet 
access to access the vendors' Web sites to manually check 

5 lists of the latest available versions of products and then to 
order the products on-line. This reduces the amount of 
paperwork involved in ordering software (and is equally 
applicable to other products). Some companies have also 
enabled their software to be downloaded directly from a 
Web site on a server computer to the customer's own 
computer (although this download capability is often 
restricted to bug fixing patches, low cost programs, and 
demonstration or evaluation copies of programs, for security 
reasons and because applying patches tends not to require 
any change to pre-requisite software or any data migration). 

5 Information about the World Wide Web can be found in 
"Spinning the Web" by Andrew Ford (International Thom- 
son Publishing, London 1995) and "The World Wide Web 
Unleashed" by John December and Neil Randall (SAMS 
Publishing, Indianapolis 1994). Use of the WWW is grow- 

o ing at an explosive rate because of its combination of 
flexibility, portability and ease-of-use, coupled with inter- 
active multimedia presentation capabilities. The WWW 
allows any computer connected to the Internet and having 
the appropriate software and hardware configuration to 

^ retrieve any document that has been made available any- 
where on tie Internet. 

This increasing usage of the Internet for ordering and 
distribution of software has saved costs for software 
vendors, but for many software products the vendor cannot 

o just rely on all customers to access his Web pages at 
appropriate times and so additional update mechanisms are 
desirable. 

As well as the problem of manufacture and distribution 
cost associated with distributing media, there is the problem 

5 that customers typically need to make considerable proac- 
tive effort to find out whether they have the best and the 
latest version and release of a software product and to obtain 
and apply updates. Although this effort is reduced when 
Internet connections are available, even a requirement for 

o proactive checking of Web sites is undesirable to many users 
since it involves setting up reminders to carry out checks, 
finding and accessing a software provider's Web site, navi- 
gating to the Web page on which latest software versions and 
patches are fisted, and comparing version and release num- 

5 bers within this list with the installed software to determine 
whether a relevant product update is available and to decide 
whether it should be ordered. There may be an annoying 
delay between ordering an update and it being available for 
use, and even if the update can be downloaded immediately 

o the task of migrating to an upgraded version of a software 
product can be difficult. If these steps have to be repeated for 
every application, control panel, extension, utility, and sys- 
tem software program installed on the system then updating 
becomes very tedious and time consuming. Therefore, 

5 manual updating tends not to be performed thoroughly or 
regularly. 

There is the related problem that software vendors do not 
know what version of their software is being used by each 
customer. Even if the latest version of their software has 

o been diligently distributed to every registered customer (by 
sending out CDs or by server-controlled on-line 
distribution), there is still no guarantee that the customer has 
taken the trouble to correctly install the update. This takes 
away some of the freedom of software developers since they 

s generally have to maintain backward compatibility with 
previous versions of their software or to make other con- 
cessions for users who do not upgrade. 
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It is known in a client-server computing environment for out requiring any interaction by the user after an initial 

a system- administrator at the server end to impose new agreement of update criteria. The update criteria can be 

versions of software products on end users at client systems associated with the products' licensing terms and conditions, 

at the administrator's discretion. However, this has only ™s ensures that users who adopt a suitable update policy 

been possible where the administrator has access control for 5 ca » always have the most up-to-date software available, with 

updating the client's system. This takes no account of users errors bein g corrected automatically from the viewpoint of 

who do not want upgrades to be imposed on them. me user - The user does not need *° where software 

. , . t - . . j . updates come from, how to obtain them or how to install 

Yet a further related problem is that software products ^ ^ ^ ^po^t takes care of this. THe 

often require other software products to enable them to softwarc VCQdor avoids havi to shi ial CDs or 

work. For example, application programs are typically writ- 30 to COfrect enors 0f provide ^^ona! features; the 

ten for a specific operating system. Since specific versions of vendor can easily release code on an incremental basis such 

one product often require specific versions of other products, mat cust omers receive new product features sooner and with 

upgrading a first product without upgrading others can result n0 effort. 

in the first product not working. An updater component according to a preferred embodi- 

"Insider Updates 2.0" is a commercially available soft- 15 ment of the invention performs a comparison between 

ware updater utility from Insider Software Corporation available software updates and installed software on the 

which, when triggered by the user, creates an inventory of local computer system to identify which are relevant to the 

installed software on a user's Apple Macintosh computer installed software, compares the available relevant updates 

and compares this with a database of available software with update criteria held on the local computer system (these 

update patches (but not upgraded product versions) and 20 update criteria are predefined for the current system or 

downloads relevant updates. "Insider Updates" shifts the s ^ tem ™*)> and then automatically downloads and applies 

responsibility for finding relevant updates from the user to so ^ arc ? dates whlC * • Salisf >' ^ mte ™- U1 

the database maintainer, but the access to update patches is . ^ autom ^ c ^ m f ° f software ^ttes PicfcrAly 

* ■ ■» j * t - . ■ j- j i j . t_ j . I involves installing available software patches and/or 

limited to a connection to an individual database and the ^ v&rs[ons % acc0 rdance with both the predefined 

tasks of scanning the Internet and on-line services to find datc Ma and mstructions for instaU ation which are 

updates and of maintaining the database of available updates down i oade d together with the program code required for the 

require significant proactive effort. "Insider Updates" does update featufe of executing dynamically downloaded 

not install the updates or modify the user's software in any instructions provides flexibility in relation to the types of 

way. "Insider Updates" does not address the problem of updates that can be handled by an updater component. It can 

unsynchronised prerequisite software products. 30 also be used to enable a single generic updater component to 

A similar product which scans selected volumes of a be used with many different software products, 

computer system to determine the installed software and Alternatively, the installation instructions for certain soft- 

which connects to a database of software titles for the Apple ware updates may be pre-coded within the updater compo- 

Macintosh, but does not download updates, is Symmetry nent. The "software resources" are typically a combination 

Software Corporation's "Version Master 1.5". 35 of program code, machine readable installation instructions 

An alternative update approach is provided by "Shaman da , ta changes such as address information, 

y i j > o i 1 <c» r ol *• • • i The information for use in identifying a network location 

Update Server l.l.o from Shaman Corporation, which . 4 , , • / *• l. 

•» r p n nm / / jj-.-l.j iix ma Y De explicit network location information or it may be a 

consists of: a CD-ROM (updated and distributed monthly) cL a ~ *u - c «- u- u 

_ v , 3J software vendor name or any other information which can 

that users install on a PowerMac file server; client software 40 be used ^ a eter for identifymg me localion . ln 

for each Macmtosh computer tobetnventoned and updated; ^ kmd embodiment the information is a product 

and means for accessing an FTP site stonng a hbrary of identifier which is ^ fa ^ da(er onent t0 a 

current updates. Shaman Update Saver* creates an inven- se&rch e ^ , 0 a search to ^ re , evant 

tory of networked computers and downloads and distributes Qetwork loca , ioQ M which are st£)red ^ KS0Wce& 

latest versions of software to each computer. Network 4J for ^1^^ upd at es to that product. This search may 

administrators centrally control this inventory and updating be performed by a conventiona i 

Internet (or other network) 

process. The distribution of CD-ROMs has the expense searcn engine which fe ca]led b me dater ooen { 

problems described earlier. wheo ^ ^ eQgme retums m identification of the 

SUMMARY OF INVENTION network location, the updater component retrieves from this 

_ , . 50 location a list of available relevant updates, checks the list 

According to a first aspect of the invention, there is ^ m6 ^ held duct version md ^ 

provided an updater component for use in updaUng one or defloed u ^ ate criteri and retrieves ^ date resollrces 
more computer programs installed on a computer system Mto me , oca , mer tem tf mose criteria m satisfied 
connected within a computer network, the updater compo- According to a preferred embodiment of the invention, a 
nent inc u ing. 55 slant jardised naming convention is used for software 
information for identifying one or more locations within resources from which to build software updates, and the 
the network where one or more required software updater component can search for these resources on a 
resources are located; Network Operating System filesystem. This allows software 
means for initiating access to the one or more locations to resources to be stored at multiple locations to mitigate 
retrieve the one or more required software resources; 60 against network availability problems and makes it easier for 
and developers and distributors to provide their error-fixing 
means for applying a software update to one of said patches and upgraded versions of software products. For 
installed computer programs using the one or more example, a developer can make new software updates avail- 
retrieved software resources. able via a public network disk drive on their LAN using a 
An updater component according to the invention pref- 65 known filename or via a published Uniform Resource Loca- 
erably controls upgrading of, and fixing of bugs within, an tor (URL) which can be searched for using known key 
associated software product or products automatically with- words. 
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Updater components are preferablyan integral part of the DETAILED DESCRIPTION OF PREFERRED 

products they will serve to u pdate. Hence, the updater EMBODIMENTS 

"component is distributed to software users together with an As shown in FIG. 1, an updater component 20 is installed 

initial version of a softwarcjjroduct, the updater component in system memory of a conventional network-connected 

"then automatically obtaining~and applying software updates s computer system 10, together with an associated computer 

in accordance with preset criteria (such as a time period program 30. The updater component may have been deliv- 

between successive searches for updates, and whether the ered to the user of the local computer system on a storage 

particular user has selected to receive all updates or only medium (diskette or CD) for him to install, or it may have 

certain updates — such as to receive updating patches but not been explicidy downloaded from another computer system, 

replacement product versions for example). 10 In preferred embodiments of the invention, updater compo- 

The updater component's update capability preferably nents arc integrated within the computer program they are 

includes updating itself. Indeed, the update criteria may be intended to maintain (or are otherwise delivered via the 

set such that the updater component always accesses appro- same mechanism and at the same time as their associated 

priate network locations to obtain updates to itself before it program) The updater component is then installed as part of 

. r f*. f j *■ * ' * a ■% e the installation procedure or its associated program, such 

searches for software resources for updating its associated is , . r . , , r . ° \ 

software roducts user ^ QOt re ^ mre ° t0 ta ^ e s P ecia J action to 

S ° An a upd P ater component according to the invention pref- obtain or a «* ate * ^ installation of each updater com- 

erably includes means for checking whether pre-requisite P 0I f * mcludes u P daler component registering itself 

products are available, and are synchronised to the required operating system (more generally, updaters regisfcr 

version, as part of the process of selecting an update path for 20 ^ * «poatory 40, which may be central or distributed), 

the current product. In a preferred embodiment, as well as such tot ally 

checkingtheiravailability,theupdatercomponentisc a pable ar£ ^entifiable and contactable by address information, 

of instructing the updater components associated with pre- meir P rochlct identifier, within the register entry, 

requisite software products to initiate updates to their soft- 11 1S a featurc of thc preferred embodiment of the inven- 

ware where this is the agreed update policy. If each software 25 1100 that each u P dater component can locate, can be located 

product's updater component is capable of triggering b ^ ™ d can communicate with other updater components 

updates to pre-requisite products, then updates can ripple which mana S e otber software products. This capability is 

through the set of installed software products without the uscd when one updater component requires another one to 

user having to be involved in or aware of the updates. This u P date to a s P ecific level before ^ former can execute its 

capability is a significant advantage over prior art updater 30 own u P dale > as ^ bc discussed below. This is enabled by 

agents which do not deal with the problem of unsynchro- the "P^tn components registering within the operating 

nised software versions when one updates, and supports the s y stem or other repository 40. 

increasing trend within the software industry for collabora- In the preferred embodiment, each registration entry con- 

tion between distributed objects to perform tasks for the end lains two items: me updater path and the updater network 

user 35 address. The path is the location of the updater component 

The updater component preferably also includes a mecha- o^ioy file so that the updat er comp o nent can be launched b y 

nism for verifying the authenticity of downloaded software, ^ operating system during the boot up process . This 

using cryptographic algorithms. This avoids the need for ensures that the updater component is always active and 

dedicated, password-protected or otherwise protected soft- ready to perform work or handle requests issued to it from 

ware resource repository sites. The software resources can 40 other updater components. The network address is the 

be anywhere on the network as long as they are correcdy address used by components on other computer systems in 

named and or posted to the network search engines. the network to locate it on the network and to communicate 

Thus, the present invention provides an agent and a with ft- 

method for obtaining and applying software updates which An example of such registration using a UNIX (TM) 

significantly reduces the cost and effort for software dis- 45 operating system and the TCP/IP protocol suite uses the 

tributors of distributing and tracking software updates and following naming convention for updater components: 

significantly reduces the effort for system administrators and SoftwareVendorName+_product_name+_updater. 

end users of applying updates to installed software. Path registrations can be entered in the UNDC/etc/inittab 

file to store the path entry. When, for example, the updater 

BRIEF DESCRIPTION OF DRAWINGS 50 component for IBM Corporation's DB2 (TM) database 

Hie present invention will now be described in more P roduc {; * iDStaUed il ^ add an CDtr y to ^ /etc/inittab file 

detail, by way of example only, with reference to the °^ ^ e * onn - 

accompanying drawings in which: ibm_db2pe_updater:2:respawn:/usr/abin/db2_updater„ 

binarv 

FIG. 1 is a schematic representation of a computer net- SJ E ^ ^ u(er tem reboots it ^ read ^ 

work including a local computer system having an installed fi|e an / launch the DB2 dater ampoMnL ^ "respawn" 

updater component, server computers storing lets of avail- fd . Q ^ f ensures ^ u ^ al£f 

able updates and storing software resources for applying ' . c i cl , • ,/„ , 

. * , t. • * i u component process fail for some reason during general 

updates, and a search engine for locatine the servers; . •« . J , , lL . 

* > 6 t> > system operation, it will be restarted by the operating system 

FIG. 2 is an example of a software vendor's list of their 60 automatica ii y . This approach will ensure that all updater 

software versions and the resources and prerequisites for components for all installed applications are always active, 

building from one version to another; Network Location registrations can be entered in the 

FIG. 3 represents the sequence of operations of an updater UNIX/etc/services file. For example when the DB2 updater 

component according to an embodiment of the invention; component is installed it will add an entry to the /etc/services 

and 65 file of the form: 

FIG. 4 is a further representation of the sequence of ibm__db2pe_updater 5000/tcp#net location of DB2 updater 

operations of an updater component. component 
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When another updater component wishes to communicate 
with the DB2 updater component it will find it by searching 
this file for the DB2 updater component name ibm__db2pe_ 
updater (actually done indirectly by the UNIX call 
getservbyname()— the name is built by the caller according 5 
to the standard naming convention). When it is found it 
knows that the DB2 updater is listening for connections on 
port number 5000 and will use the TCP protocol. This allows 
the updater component in question to establish a link to the 
DB2 updater component and start a conversation (described 10 
later). 

For an updater component to find and talk to another 
updater component on another remote machine the above 
information would have to be augmented by having a 
repository 40' which is accessible from both machines 15 
(preferably a central or distributed database accessible from 
anywhere in the network, such as a Web Page or pan- 
network file) and is available to all updater components that 
require it. Entries would be of the form updater_jiame 
machine_ip_address (OR DNS entry), port number, pro- ^ 
tocol. 

For example, the manufacturing department of an organi- 
sation may have three computer systems on which distrib- 
uted software products collaborate with each other, the 
systems being called a, b and c. Typical entries in the Web 25 
page or file manufacturin&_„collaborators.html might be: 
ibm__catia_updater a. manufacturing.com 5000 tcp 
ibm_db2pe__updater b. manufacturing.com 5100 tcp 
ibm_cics_updater cmanufacturing.com 4780 tcp 

An updater component can then connect and talk to any 30 
other updater component using the DNS name to create an 
IP address and the port number which the remote updater 
component is listening to at that address. 

The steps of updater registration at installation are there- 
fore: 35 

1) Create entry in /etc/inittab file (register updater process 
code location) 

2) Create entry in /etc/services file (register updater 
process local address) 

3) Create entry in central database file (register updater 40 
process pan-network address). 

The installation process may also involve providing to the 
updater component the local IP address of a Web proxy 
server. It will be clear to persons skilled in the art that many 
alternative registration implementations are possible. 45 

Updater components include data fields for an identifier 
and version number for their associated software products. 
The updater components may be delivered to customers with 
these fields set to null values, and then the installation 
procedure includes an initial step of the updater component 50 
interrogating its software product to obtain an identifier and 
current program version and release number. Alternatively, 
the software vendor may pre-code the relevant product ID 
and version number into the updater component. 

The system 10 of FIG. 1 is shown connected within a 55 
network 100 of computers including a number of remote 
server systems (50,50*) from which software resources are 
available for applying updates to programs installed on the 
local system 10. Each server system includes within storage 
a list 60 of the latest versions of, and patches for, software 60 
products which are available from that server. Each vendor 
is assumed here to make available via their Web sites such 
a list 60 of software updates (an example of which is shown 
in FIG. 2) comprising their product release history, in a 
format which is readable by updater components, and to 65 
make available the software resources 70 required to build 
the releases from a given level to a new level (this transition 



from a software product release to a new level will be 
referred to hereafter as a 'growth* path). The entries in the 
software updates list 60 include for each software product 
version 110 an identification 120 of the software resources 
required for applying the update and an identification 130 of 
its prerequisite software products and their version numbers. 
In some cases, the required resources are complete replace- 
ment versions of software and associated installation 
instructions. In other cases, the resources comprise patch 
code for modifying an existing program (e.g. for error 
correction) and the patch's installation instructions. 

For the current example, we will assume that the network 
100 is the Internet, although the invention may be imple- 
mented within any computer network. Also shown within 
the network 100 is a server system 80 on which a search 
engine 90 is installed for use in finding update source 
locations on the network. This is shown located remotely 
from the local system 10, although it need not be. In the 
Figure, each updater component 20 is shown associated with 
a single program 30, and it is a feature of this embodiment 
of the invention that all installed software products have 
associated updater components which manage them, but 
neither of these features is essential to the invention as will 
be explained later. 

The operation of an updater component will now be 
described, with reference to FIGS. 3 and 4. When an 
installed updater component executes, its first action is to 
initiate 200 a search for available updates to the particular 
software product, providing to one or more search engines 
90 as search arguments the product identifier and product 
version release number obtained at install time. Assuming 
that software vendors provide via their Web sites a list 60 of 
available product updates referenced by product identifier 
and release number 110 (or some other consistent naming 
convention is used), the search should identify the relevant 
Web site 140 on which update information is available. If the 
initial attempt to start a search engine is unsuccessful, then 
the updater component will attempt to start a different search 
engine (which may be in a different geographical location to 
the first), but could alternatively wait for a preset time period 
and then retry. A URL identifying the relevant Web site 140 
for update information is returned 210 to the updater com- 
ponent as a result of the search. 

The updater component uses the URL to access 220 the 
list 60 and downloads 230 a file 160 comprising the portion 
of the list 60 of available updates which relates to the 
particular product. The updater component then performs 
steps 240-280 as shown in FIG. 4. Each file 160 contains 
message digests (e.g. MD5) which are digitally signed. The 
retrieved file 160 is then analyzed 240 using a digital 
signature checking algorithm (such as the algorithm 
described in U.S. Pat. No. 5,231,668). This is important to 
verify that the file 160 represents the correct software 
updates list for the particular software product, and that the 
file has not been tampered with since signing. Also, check- 
ing for the digital signature is a useful way of filtering the 
results of the search since these may include a plurality of 
Web page URLs other than the correct one (the search may 
find other pages which have a reference to the named 
product version, including pages not published by the soft- 
ware vendor). If an attempt to download and verify a file is 
not successful, then the updater component moves on to the 
next URL found in the search. 

The updater component then performs on the local com- 
puter system a comparison 250 between the current installed 
software product's identifier and release number and the 
listed available updates in the retrieved file 160. This com- 
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parison determines possible growth pains from the current to As shown in FIGS. 3 and 4, if required software resources 

updated versions, but these possible growth paths are then for building the updated version are not found on the local 

compared 260 with predefined update criteria, and any system, the updater component submits 320 a further request 

possible paths which do not satisfy the update criteria are to one or more s earch engines to find the required resources^ 

discarded. Thus, the updater component determines whether s The search engine returns 330 one or more URLs and the 

it is possible to migrate from a current software product to updater component uses these to retrieve 340,350 the soft- 

the available new versions and whether it is possible to apply ware resources into storage of the local computer system. At 

patches to the current version under the currently agreed mis f ta S e ; u P^ter component or the user need not have 

licence terms and conditions. ^ *n™l<*gt of what corrections or enhancements may be 

For example, the software product licence may enable io m ^ cd m f thc ?™ version-Hhe update criteria determine 

. r r - c tt _ , t / what type of updates are required such that the user is spared 

migration to any future version of the product and applica- ~ r . r * j ■ 4 l . * r j . t 

4 . to c i.i . i_ , . . the effort of studying the content of every update. In 

tion of any available patches, or only migration up to a ^ h fa dQ&M for ^ tQ be ^ tQ ^ termine me 

specified version, or it may only permit applying of available effects of dates md M the resources for the 

patches which modify or correct errors m the current ver- update a description of thcse effects which a user or 

sion. Possible update paths which are unavailable due to 15 administrator can read. 

current license limitations are notified 270 as a system As examples, the software product to be updated may be 

generated message sent to the software asset manager (who a word processor application program. If the word processor 

may be an end user or IT procurement manager) of the as sold missed certain fonts or did not include a thesaurus, 

currently installed version, to enable them to make decisions patches may subsequently be made available for adding 

about whether the current licence is adequate. 20 these features. The updater component has the capability to 

As well as licence restrictions as to the updates that are add these to the word processor, subject to the update 

possible, an updater component's update criteria or growth criteria. 

policy includes a cycle period (for example weekly or In alternative embodiments of the invention, the search 

monthly) and criteria for determining which of a plurality of for required software resources is unnecessary following the 

possible growth paths to select (such as always select latest 25 initial search for the updates list (or is only necessary where 

version permitted by licence, or always select latest patch there are pre-requisite software products as well as patches 

and only notify availability of new versions, or only select or new versions for the current product — see below). This is 

new versions if prerequisite software is already available on because the update software resources required directly by 

local system). The growth criteria may also include control the current product are stored in association with the list of 

information such as when to upgrade to new versions that 30 required resources. That is, the list includes a pointer to the 

are downloaded by the updater component — if data migra- network location of the required resources such that a 

tion is required when migrating to a new software product selection of a growth path from the list involves a selection 

version it may be essential for this to be done outside of of a pointer t o the network location of the required updates 

office hours or only at a single scheduled time each month (and possibly also pointers to the locations of pre-requisite 

or each year and this can be controlled by the updater 35 software products). 

component. A second verification by digital signature checking is 
The growth policy definition may also include a param- performed 360 (see FIG. 4), this time on the downloaded 
eter determining that updating of pre-requisite software resources. After verifying 360 the legitimacy of the down- 
products should be requested when required to maintain loaded resources, the updater component automatically 
synchronisation with the current product. This will be 40 builds 310 the installation in the target environment in 
described in more detail below. Persons skilled in the art will accordance with the update policy. In practice, this may 
appreciate that there is great flexibility in the criteria that can require information from the user such as an administration 
be set and applied by the updater component. password, or a database usage parameter value, but in the 
The updater component then decides 280 on a particular preferred embodiment of the invention installing of the 
growth path (i.e. which available version to upgrade to) from 45 downloaded code is automatic in the sense that it does not 
the set of possible growth paths using the update criteria. For require the user to know or obtain from elsewhere any 
example, the updater component may select the highest installation information and in that it generally enables the 
possible version or release number of the available updates user to be freed from making any decisions at run time if the 
which is permitted by the update criteria, if that is the update predefined update criteria enable the updater component to 
policy. 50 automatically apply updates. 

The updater component performs 290 (see FIGS. 3 and 4) It is well known to include machine readable installation 

a scan of the operating system file system to check whether instructions eocoded in a shell (for example as Script, or an 

the required software resources are already available on the interpretive language such as PERL, or an executable such 

_local com puter s ystem. The required resources are the as setup.exe in the case of applications on Microsoft's 

software update artifacts required to bring the current appli- 55 Windows (TM) operating system). Updater components 

cation software to the new level, and the software updates according to the invention will download 350 the machine 

required for updating pre-requisite software to required readable instructions together with the relevant software 

levels. Each updater component associated with pre- resources and will automatically execute them 310. Thc 

requisite installed products is contacted 300 to ensure (a) updater component thus automatically processes installation 

that it is installed, and (b) that it is at or greater than the 60 instructions, avoiding the input from a person which is 

required pre-requisite level. If all required resources are conventionally required. The Scripts can be adapted to reuse 

available locally or on another machine (in the case of information gleaned from thc first human installer who 

software relying on some pre-requisite software operating installed the first version of the updater component (for 

on a remote machine), and have been verified, then the example, information such as user name and password of 

updater component progresses to the step 310 (see FIG. 4) 65 application administrator, installation directory, etc), 

of building the updated software version. If not, the update The method of updating according to the preferred 

component must obtain the required resources. embodiment of the invention requires software vendors to 
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organise the software resources required to build from one Possible_Growth_Paths: 

product level to another. For example, a move from version transient data representing the available upgrade paths 

1.1.1 to 1.1.4 would typically include a series of patches to (e.g. version numbers 3.1.d, 3.2.e, 4.0.a) 

be applied, and the required order of installation if any PRIVATE UPDATER FUNCTIONS: 

would advantageously be encoded in machine processable $ The updater component logic includes the following 

installation instructions. The user is then spared the effort methods: 

and the risk of human error which are inherent in methods Discover_Possible__Growth_PathsO 

which require the user to control the order of application of Search for Growth_Path information for this software 

fixes and enhancements. The problem of how to migrate pro duct on the Internet (or Intranet or other network). This 

from one product level to another is thus dealt with by the w search method a search ^ a sUmdard en ^ e 

software vendor instead of the customer, and updater com- server ^ mformation returned ^ a to of newer versions 

ponents can only move to levels supported by the vendor ^ &ssoM pre . rcquisitc product mform ation. 

(i.e. those growth paths published by the software vendor for ™ „ r n 4 . . - \. . 4 , , , . 

a specific existine product level) Growth_Path information is then reduced in accor- 

The updater generates 380 a report and writes 390 to log dan ^ c ^ ^ Growth policy parameters. For all members 

records, and then quits execution 400 (in the preferred * m me Growm_Paths hst, a cbeck is performed of whether 

embodiment the updater goes into a sleep or idle state) until appropriate versions of pre-requisite products arc available 

activated again 410 upon expiry of a predetermined update on tne local ^ 0T remote computer. The updater compo- 

cycle period (the repeat period parameter is configured when nents managing these pre-requisite products are accessed 

the updater component is installed). and forced t0 g row lf ^ is & G P olicv - 

Structure of Updater Component 20 If all pre-requisite products exist locally at the correct 

The structure of an updater component comprises data, level > or m available remotely on the network and there is 

methods for operating on that data, and a public application a " force & owih " P olicv > identifiers for newer 

programming interface (API) which allows other updater versions of the software product are added to the Possible_ 

components to contact and communicate with it. This struc- Growth_Paths list, 

ture will now be described in detail. 25 Decide„_Growth_Path() 

UPDATER COMPONENT DATA: Interpret the growth policy and select a single growth 

The updater component includes the following persistent P ath - Some implementations of the invention will involve 

data . user interaction to select the path, for example if there are 

Product_ID: an identifier of the software product which considerations such as whether to force updates to other 

is managed by this updater component 30 P r °S ram s. 

Current_Installed_Version: a version identifier for the „ e esources^ arameer. ° s ^ n — r ° a ) 

. 4 „ . - 4 , ■ o i a\ Given Chosen Growth Path (e.g.3.2.0), search for 

installed software (e.g. version 3.1.0) . , — /n ~~ 5 . /A ^ 

_ T . required resources (Parameters Product_ID, Current_ 

Current License: a version identifier corresponding to Installed _Version, Chosen„Growth_Path), download alt 

the software product version up to which the current 35 fesources tQ ]ocal ^ r ^ ^ mdude software 

software license allows the user to upgrade <e.g ver- ^ for ^ new yersion ^ machine essable 

sion 4.0.z) A^temauvely this may be a licence identi- mslallation mstructions . 

fier (e.g. LIC1) for use when accessing machine read- Install ResourcesO 

able licence terms. Process installation instructions including installing 

Installation Environment: • A C1 . . 4 ^ U1 t *• % 

— 40 required nles in correct locations, possibly compilation of 

a list of attribute name/attribute value pairs. the files and modifying tne configuration of the existing 

This is used by the updater component to store values system t0 accommodat e the software, togging all actions to 

entered by the user when the updater was used for the first a file (and enabliDg ari « un install" method to undo all 

time. For example, the updater installation userid and actions) 

password, possibly the root password, the installation 45 Grow() 

directory, the web -proxy server address, search engine Initiates methods* 

URLS, log file name, software asset manager e-mail address Disco ver„Possible_Growth_Paths() 

etc mis data will be re-used when subsequent automatic . f qq fc ^ ^ ^ f Q&Qt 

updates are required. bccomes {dk d$c 

Growth policy parameters: 5Q Decide _Growth_Path0 

a. Growth_Cycle: data determining whether the updater Get_Resources(Parameter: Chosen_Growth_Path) 
component should attempt to update its software prod- Install ResourcesO- 

net every day, week or month, etc. Thcn q tqwo all comple ted actions to log and 

b. Growth__Type: data determining whether the updating finishes execution of the updater component. The updater 
is limited to bug fixing and enhancements (i.e. patches) 5S component becomes idle either until time to check again for 
only or requires upgrading to the latest release in each new upda te requirements or until prompted by another 
growth cycle. updater component to do so. 

c. Force_Growth: (YES/NO) a parameter determining PUBLIC UPDATER COMPONENT API: 

whether to force other software resources to upgrade if The updater component includes the following public 

that is a pre-requisite for this software to upgrade. 60 API. These functions would be callable using existing 

(Some implementations will provide more flexible con- network communications software, such as remote proce- 

trols over forcing other software to update than this dure calls, message oriented middleware, ORB (Object 

simple YES/No) request broker), etc. 

Last_Growth Time: Date and time when updater com- Get_J*elease() 

ponent last executed 65 This function is called by other updater components and 

The updater component also includes the following non returns the release level of the product managed by this 

persistent data: updater component. 
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Update(new_level) can talk to another updater component anywhere on a 

Other updater components call this function to move the network. In this example the component updater registration 

product managed by this updater component to a new level database 40 is a directory or folder available over the 

indicated by the new_Jevel parameter value. This will call network (e.g. via NFS) which contains for each installed 

the private function GrowQ. 5 updater component a file called "updater-component_ 

Receive_Event(event details) nameiop" (iop stands for interoperable object reference). 

When an updater component receives a request to update, file contains a sequence of bytes which can be 

it must inform the calling updater component when it has converted into a reference to the updater component by any 

completed the update or otherwise e.g. if it failed for some up dater component which reads the file using for example 

reason. The updater component performing the update on 10 me CORBA function: 

behalf of another updater component will call this function ™r»n A ^. t t - 4 l/v • ^ 

f , • j * *. • ♦ CORBA: :Obiect::_stnng_to_obiect0 in C++ 

of the requesting updater component to communicate sue- J * J v 

cess of the update or otherwise. Event details can be a string Furthermore this reference can be to an updater compo- 

like "product id, new release level, ok" or "product id, new nent anywhere on the network as it represents a unique 

release level, failure". 15 address for the corresponding updater component. When 

The automatic handling of the potential problem of updater component A has manufactured a reference to 

unsynchronised pre -requisite products by enabling forcing updater component B then updater component A can call a 

of updates (or, if forcing of updates is not part of the update P^Mic API function simply by using, for example, a C++ 

policy, sending of notifications to the software asset mapping A-* Get_Release() which will then return the 

manager) is a significant advance over prior art update 20 valuc °f thc release level of the software managed by the A 

schemes. updater component. 

Since the updates list file 160 returned to the updater In this example we will consider two products — IBM 

component in response to an initial search includes an Corporation's DB2 database product and a Query Tool 

identification 130 of pre-requisite software, that information called "Query Builder", on different machines M and N 

enables the aforementioned examination 290 of the updater 25 respectively. (Machines M and N could be the same 

component registration database 40,40' to check whether machine; the present example merely shows that they may 

pre-requisite software is available locally or remotely. If it also be separate). Both products have updater components 

finds all the updater components located locally or remotely, which use a CORBA ORB architecture as briefly outlined 

it can be sure that the software p re-requisites are available above. An ORB communication daemon is active on par- 

and it next needs to contact each updater component for each 30 ticipating systems M and N. 

software product to be sure all pre-requisites are at the Step 1) Registration Phase: 

correct level. If an updater component 20* having a required The DB2 Updater Component starts when the operating 

product identifier for pre-requisite software 30' but not system starts on system M and immediately creates a file 

having the required version number is found locally or called ibm_db2__updater.iop (according to some naming 

remotely, and if forcing of updates is the update policy, then 35 standard used to aid subsequent searches for the file) in the 

the updater component 20 of the first computer program network file system folder or directory. This directory could 

contacts 300 this pre-requisite updater component 20' and be hosted on any machine and not necessarily M or N. The 

requests that it attempt to update its associated pre-requisite file contains a series of bytes which can be used to manu- 

software product 30'. This updater component 20' can, if facture a reference to the updater component, 

necessary, request other updater components of its pre- 40 [pseudocode] 

requisite software to update their versions, and so on. Filehandle=open("/network/filesystem/directory", "ibm_ 

If at some stage no relevant updater component is found ^2 updater iop")' 

locally or remotely, then a message is sent to the asset Referen"ceBytes=CORBA::Object::_object_to_string0; 

manager to inform him/her of the requirement for a new Write(FileHandle, ReferenceBytes); 

product in order to grow the associated product further. If at 45 close(File handle); 

some stage during the chain of updater requests to grow to Query Builder Updater component starts and writes its 

a new level one updater component fails to move to the registration to the same directory or folder, again in this case 

required level then this failure is reported back to its calling calling the file ibm_querybuilder„updater.iop. 

updater component, prompting failure of that components ^ t ^ stage Dotn up d a ter components are active and have 

update operation, and so on back to the updater component 50 registered their presence and location in the network direc- 

which initiated the whole transaction. t orv 

Thus, as well as their autonomous behaviour defined by § te p 2) 

their update criteria, updater components can react to exter- QueryBuilder attempts to grow from version 1 to version 

nal stimuli such as requests from other updater components. 2 bm a prerequisi te is DB2 version 2.1 or higher. The 

Example of Update Synchronisation 55 following sequence of actions will occur. QueryBuilder is 

, - . . , - , , denoted QB and DB2 as DB2. 

An example of the implementation of update syncbroni- ^„ , - , . /C1 

, . r ^ f , .„ . j -j_ 1 t*i_ * QB: searches for file ibm_db2_updater.iop (file name 

sation between two products will now be described. This f ^ , ,. 4 * j j\ ■ * 1 j • * Ti 

-•I 1 j * . manufactured according to standard) in network directory. It 

example shows how one updater component can commum- ~ , , . , . v , . , - 

t r . , 4 l • fiaos the file, reads it and converts it to a usable reference, 

cate with another to synchronise pre-requisite software so 60 r . \ 

that all products are present and at compatible release levels. [pseudocode J 

A CORBA (Common Object Request Broker if (dbrefoCORBA:: Object: :_ s tring_to_object(readfilc 

Architecture) ORB (Object Request Broker) is used for (ibm_db2_updater.iop))) 

location of and communication between two updater com- tneQ SUCCESS we have connected to the updater else 

ponents. Using the above public API it is a simple matter for 65 FAIL: Prerequisite software does not exist in set of 

those familiar with the art of CORBA programming to collaborating systems — send e-mail to software asset 

develop communication code so that one updater component manager to notify situation. 
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Give up on trying to grow to new version. 

endif. 

Step 3). 

At this stage we know that DB2 exists somewhere in our 
set of networked computers. Now we need to know if it is 
at the right level. We simply do this by executing its public 
API function Get_Release() defined above, from within the 
QB updater, the QB updatcr is therefore a client requesting 
the DB2 updater to do something for it, i.e. tell it what 
release it is. 
[pseudocode] 

db2_release=dbref-^Get_ReleaseO; 

Let us say this returns the value "2.0". 
Step 4) 
Client Side: 

The QB Updater Component knows that this is not 
sufficient , it requires version 2.1. It examines its Force_ 
Growth parameter which is, for example, "YES" meaning it 
should force pre-requisite software to grow to the level 
required before it can perform its own update procedure. 
Therefore the QB updater tells the DB2 updater to grow to 
the new release, and then waits until the pre-requisite has 
grown to the new release or failed in doing so. 
[pseudocode] 

dbref->Update("2.1", QBref); // QBref is a ready made 
reference to the // QB Updater. It is passed to the DB2 
updater so that // it can quickly send the results, success 
or failure, // when the DB2 Updater has finished trying to 
update // itself. 

EVENT=null; 

While (EVENT equals null) 

{do nothing;} 
if (EVENT equals "SUCCESS") 

then attempt to grow software managed by this updater 
component i.e. Query Builder. 

else 

Write failure to log; 
do not attempt to grow; 
go to sleep and try later, 
endif. 

Server Side: 

The DB2 Updater component receives the request to 
grow. Which it attempts to do. 

It reports the result to the calling client (it knows how to 
contact the calling client as it is receives a reference to the 
caller in the function call.) 
[pseudocode] 
DB2 attempts to grow, 
if Growth Successful then 

QBRef^Receive_Event("SUCCESS"); // Note the 
implementation of the // function Receive_Event sim- 
ply sets the variable // called EVENT in the QB 
Updater component to the // value of the parameter 
passed in the API call , i.e. // "SUCCESS" if in this 
section of the IF statement. 

else 

QBREF^Receivc _J£vent("FAILURE"); 
end if 

As noted previously, predefined update criteria may deter- 
mine which of an available set of updates should be applied 
and which should be disregarded. The update criteria may 
include an instruction to the updater component to send a 
notification to the end user or system administrator when a 
software update is identified as being available but applying 
this update is not within the update policy or is impossible. 
One of the examples given previously is that the update 
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policy may be not to install full replacement versions of 
software products since that may require upgrading of 
pre-requisite software products or migration of data (for 
example if the software product is a database product), 

5 whereas it may be intended policy to install any error- 
correction patches. Notification rather than automatic instal- 
lation of updates may also be implemented where to upgrade 
one product to a new version would require upgrading of 
other pre-requisite complementary products. 

10 The update policy can also determine the degree of 
automation of the updating process, by defining the circum- 
stances in which the updater requests input from the user or 
administrator. 

The execution of a particular example updater component 
15 will now be described in more detail by way of example. 
This updater component's function is to keep an installed 
product called "Test" totally up-to-date with all released 
patches, but not to install replacement versions of Test. 
Firstly, the updater component is configured with the fol- 
20 lowing data instantiations: 
Product_ID: Test 
Current_Installed_Version : 1 .0 .a 
Current_TJcense: LIC1 
25 Installation_Environment:"USERID :TestO wner, 
USERPASSWORD:easy" 
"INSTALLPATH: /usr/bin/testapp/" 
Growth__Cycle: weekly 
Growth_Type: patches, latest, automatically 

30 Force Growth: no 

Last_Growth_Time: Monday Aug. 10, 1997. 
The updater then executes weekly, for example each 
Monday night at 3 am (it is the system administrator who 
35 decides the timing). 

The following represents a possible execution trace for 
this example updater component. 

Example Execution Trace 
Step 1) The Growth Cycle Starts: 
40 »» START: Discover_possible_Growth_PathsO 

* Execute search on remote search engine (e.g. Internet 
Search Engine) using Phrase ("IBM Test l.O.a Growth 
Paths") 

45 Search returns URL published by software vendor out- 
lining current growth paths for product; 

* Download URL: 
File contents are: 

"1.0.b,none; 2.0, other_required product__product_id 
50 l.O.c;" 

* Authenticate URL file using hashing algorithm and 
digital signature. 

If not authentic, return to search for another URL match- 
ing criteria 

55 * Build growth_path_list: growth_path list="1.0.b, 
none; 

2.0, other_required_product_id l.O.c;" 

* Remove all but patch level increases (according to 
6Q Growth^J'olicy) from Growtb^path list (i.e. only 

those with the first version and second release number 
matching 1.0). 

* growthjath list="1.0.b, none;" 

* For all members in list, ensure prerequisites exist In this 
65 example, all members of list meet this criteria trivially. 

* Place candidate growth__paths into Possible__Growth_ 
Paths list-l.O.b 
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«« END: Discover_possible_Growth_Paths() 
Step 2) Next the updater component decides on the Growth 
Path to pursue: 

»» START Decide_Growth_Path() 

* The growth policy dictates that we should grow to latest 
patched 

revision. (In this example, determining the latest revision 
is trivial i.e. it is l.O.b) 

* chosen growth path=1.0.b 

«« END: Decide_Growth_Path() 
Step 3) The updater component then obtains the required 
resources to revise the current software level to the new one. 

»» Get_Resources() 

* Execute search on remote search engine (e.g. Internet 
Search Engine) using Phrase ("IBM Test REVISION 
l.O.a to LO.b 

RESOURCES"). 

* Search returns URL say 

ftp ://f tp .vendor-site/pub/test/resource s/1 .0. a-b " 

* Updater downloads file pointed to by URL and places 
in secure holding area where it verifies authenticity. 

* Updater verifies authenticity (using, for example, digital 
signatures based on RSA algorithm, or any method) 

If files not authentic, then return to search (see Note 1 
below) 

* Updater unpacks resources into a temporary directory 
(see Note 2 

below). These resources include machine processible 
installation 

instructions (for example, instructions written in a script 
language such as a UNIX shell script or MVS REXX) and 
files 

(either binary or requiring compilation) which actually 

contain 
the software fix. 
«« END: Get__Resources() 
Notes on above tasks 

Note 1 — To save time the updater looks for a standard file 
before downloading the URL called "signature", which 
contains the URL 

ftp://ftp.vendor-site/pub/test/resources/1.0.a-b and a list- 
ing of its contents. This is hashed and signed. Using this 
signature, the Updater component can quickly establish 
authenticity of the URL (to some extent) before down- 
loading it and use the information i.e. file listings to 
corroborate the final downloaded resources after they 
have been unpacked into the temporary directory. 
When the final URL is downloaded it is also checked 
again for authenticity (to guard against someone plac- 
ing a bogus artefact in an authentic URL location). 
Note 2 — Part of the unpacking is that the updater com- 
ponent will examine the installation scripts and modify them 
based on the contents of its installation environment data 
where required. For example if the installation instructions 
were coded in a shell script it will replace all instances of 
INSTALLPATH with the token 7usr/bin/testapp/". Again 
Naming conventions of attributes are standardised as it the 
method of token substitution in installation instructions. 
This makes totally automatic installation possible. 

Step 4) The updater component then implements the 
actual software upgrade: 

»» START Install_ResourcesO 

* execute the installation instructions. 
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* update the values of 
Current_Jnstalled_Version= 1 ,0.b 
Last_Growth_Time =Date+Time. 

* send an e-mail to software asset manager informing of 
installation and whether or not a reboot of the Operating 

System 

or restart of the application is required before the upgrade 

takes affect. 
«« END Install_Resources0 

This is the end of this current growth cycle. The seed 
updates the Last_Growth_Time value the current time and 
then exits. The time taken for this cycle could be anything 
from a few seconds where the updater component found no 
upgrade paths for the currently installed version to several 
hours if a totally new release from the current one is to be 
downloaded and installed together with new pre-requisite 
software. 

An alternative to the embodiment described above in 
detail does not require an independent updater component 
for every different software product, but uses a single 
generic updater component installed on a system together 
with product-specific plug-in objects and instructions which 
are downloaded with each product. These objects interop- 
erate with the generic code to provide the same functions of 
the product-specific updater components described above. It 
will be clear to persons skilled in the art that the present 
invention could be implemented within systems in which 
some but not all application programs and other software 
products installed on the system have associated updater 
components, and that other changes to the above-described 
embodiments are possible within the scope of the present 
invention. 

What is claimed is: 

1. A computer program product, comprising computer 
program code recorded on a computer readable recording 
medium, the computer program code comprising an updater 
component for use in updating one or more computer 
programs installed on a computer system connected within 
a computer network, the updater component including: 

means for initiating access to one or more identifiable 
locations within the network where one or more 
required software update resources are located, to 
retrieve the required software update resources; 

means for performing a comparison between software 
update resources available from said one or more 
identifiable network locations and computer programs 
installed on said computer system, to identify available 
relevant update resources, and for comparing the avail- 
able relevant update resources with predefined update 
criteria corresponding to applicable software licence 
terms and conditions; 

means for initiating retrieval of software update resources 
which satisfy said predefined criteria; and 

means for applying a software update to one of the 
installed computer programs using the one or more 
retrieved software resources. 

2. A computer program product according to claim 1, 
wherein said means for applying software updates includes 
means for installing available relevant software resources in 
accordance with the predefined update criteria and in accor- 
dance with computer readable instructions for installation 
which are part of the software resources downloaded for the 
update. 

3. A computer program product according to claim 1, 
wherein information for identifying one or more locations is 
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held by said updater component and includes a product 
identifier of a computer program product, the updater com- 
ponent being adapted to provide said product identifier to a 
search engine, the product identifier serving as a search 
parameter for use by said search engine to identify network 5 
locations. 

4. A computer program product according to claim 3, 
wherein said updater component is adapted to download a 
list of available software update resources and their pre- 
requisite software products in response to said search engine 10 
identifying network locations at which said list is held, to 
compare the list of available software update resources and 
pre-requisite products with computer programs installed on 
said computer system and, where updates to the pre- 
requisite products are required, to request updates to the 15 
pre-requisite products. 

5. A computer program product according to claim 1, 
wherein the updater component has machine readable instal- 
lation instructions for installing the updater component on a 
computer system, the installation instructions including 
instructions for registering the updater component with a 
repository which is accessible by other updater components, 
such that the updater component is identifiable and con- 
tactable by other updater components. 

6. A computer program product according to claim 5, 
wherein the updater component includes an API via which 
updater components of complementary computer programs 
can request that the current updater component update its 
computer program, the current updater component being 
adapted to call an update method to update its computer 30 
program in response to an update request, and wherein the 
current updater component is adapted to send a system- 
generated request to updater components of pre-requisite 
computer programs of its computer program when updating 

of its computer program requires updating of said pre- 35 
requisite computer programs. 

7. A computer program product according to claim 12, 
wherein said means for applying updates is adapted to install 
correction and enhancement software which modifies exist- 
ing installed software and also to install upgraded versions 40 
of installed software which replaces installed software. 
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8. A method for automated updating of a computer 
program installed on a computer system connected within a 
computer network, including the following steps: 

delivering to the computer system an updater component 
for use in updating the computer program; 

providing at a first network location downloadable soft- 
ware resources for building said computer program 
from a current version to an updated version; 

wherein the updater component is adapted to perform the 
following steps when executed on the computer sys- 
tem: 

(a) initiating access to said first network location at 
which said software resources are located; 

(b) v performing a comparison between software 
resources available from said first network location 
and the installed computer program, to identify 
available relevant update resources, and comparing 
the available relevant update resources with pre- 
defined update criteria corresponding to applicable 
software licence terms and conditions; 

(c) downloading onto said computer system the avail- 
able relevant software update resources which sat- 
isfy the predefined update criteria; 

(d) building said computer program from the current 
version to the updated version using the downloaded 
software resources. 

9. A method according to claim 19, including providing at 
a second network location, identifiable from information in 
the updater component, a computer readable list of available 
updates to said computer program, wherein the updater 
component is adapted to perform the following steps prior to 
accessing said first network location: 

initiate access to said second network location to retrieve 
said list; 

read said list and perform a comparison of the listed 
available updates with said computer program on said 
first computer system, thereby to identify the available 
relevant update resources. 
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(57) ABSTRACT 

The present invention relates to a method and apparatus to 
permit a computer to boot from power up from its own 
memory units or from a network. The booting process is 
divided into the five stages of start-up, discovery, software 
download, software initialization and datafill. A boot ROM 
directs the stages in the booting process and the policy 
governing each of these five stages is laid out in a policy file. 
Each of the stages may be driven by the computer node's 
local memory unit, such as a local hard disk or non-volatile 
RAM), or from a software system downloader and configu- 
ration manager situated elsewhere in an ATM network where 
the computer node resides. A failure recovery procedure is 
also provided to allow the computer to revert to other means 
in case of failure during the booting process. The invention 
also provides a machine readable medium comprising a 
program element to implement the novel boot-up procedure. 
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PROCESS AND APPARATUS FOR program element for directing a computer to effect a multi- 

INITIALIZING A COMPUTER FROM stage boot-up procedure from power-up, said multi-stage 

POWER UP boot-up procedure including at least two successive stages, 

said program element implementing functional blocks, 

FIELD OF THE INVENTION s including: 

a boot element for initiating one stage of said boot-up 
This invention relates to a process and apparatus for procedure- 
starting up a computer system. It is applicable to computers a da(a a mter to , , ocation 
operating in a distributed network environment and may be information element, said boot element capable 
used to allow the individual computers to boot selectively o{ mteracti ^ ^ ^fo^io,, element t0 cauS6 
from a local memory unit or from a network through the use executioQ of * Qf ^ ^ ^ foUow . 
of a policy file. The invention also provides a computer ordef said intef ^ ^ 
readable storage medium containing a program element to » tQ in( (o ei(hef one of a ^ ^ and 
direct a computer to boot-up. a remote site. 

BACKGROUND 15 ^or ^ e P 111 ? 056 °f m is specification, the expression "local 

site" refers to a location that is in the computer itself or, 
Booting is the process by which software (usually the generally speaking, part of the computer. For example, a 
operating system) is loaded into the memory of a computer disk drive either internal or external is considered local 
and begins execution. Booting may also include loading a because it is integrated to the structure of the computer. On 
software image and starting software instances such as 20 the other hand, "remote site" is considered a location hold- 
accounting or mail daemons. Usually, booting is done when fng components that are not normally part of the computer, 
the computer is turned on. Different computer systems can but with which the computer may be able to communicate, 
boot in different fashions. For example, most PCs are able to For example, a node in a network to which the computer is 
boot their operating system from a disk containing the connected is considered to be "remote" because the node is 
required booting software and many embedded systems are 25 normally a separate device from the computer, although the 
able to boot from a pre -configured boot ROM. One type of computer can communicate with that node through a pre- 
network organization method involves using diskless work- determined protocol to exchange data, 
stations attached to a server that contains software programs For the purpose of this specification, the expression 
and data. Diskless workstations are able to boot from a "vintage of a file" or "vintage" is used to designate the age 
network using a connection protocol such as the TCP/IP 30 or time characteristics of a file that indicates whether the file 
protocol suite and download the programs in order to run is up to date or not. 

them remotely. In these systems the elements of the TCP/IP For the purpose of this specification, the expression 

protocol suite must also be fetched from a remote source and "non-volatile storage" is used to designate a storage unit that 

the booting is usually done from an IP network. maintains its content even if the storage device has no power 

In a typical system, when a computer is first turned on, 35 such as non-volatile RAM (NVRAM) or a hard-disk, 
code present in a boot ROM is executed. Typically this code In accordance with the present invention, the machine- 
directs the computer to check for hardware components to readable storage medium holds a program element imple- 
ensure no essential components are lacking in the system. menting a boot*up procedure. That procedure is character- 
The boot ROM code then proceeds in loading up the ized as being a multi-stage process. A data structure 
operating system software. In the majority of computer 40 containing a pointer that can be selectively set to point 
systems, the booting procedure is hard-coded. For instance, toward a local site or a remote site indicates the location of 
a computer that boots from its hard disk always boots from software or data components necessary to complete the 
its hard disk and one that boots from a network always boots execution of one or more of the boot-up procedure stages. In 
from a network. Modifying the booting procedure involves a specific example, this provides a flexible booting strategy 
reprogramming the boot ROM. Therefore if the hard drive of 45 allowing initiating the boot-up procedure locally while load- 
computer that boots from its hard drive fails, the computer ing some software components from a remote site, such as 
cannot start although the same software could be available a network. The components that one may select to load from 
from the network. The reverse is also true for a computer the remote location can be those that may be the subject of 
that usually boots from the network when the latter fails. repeated upgrades or revisions. This avoids the necessity of 

Thus, there exists a need in the industry to provide an 50 changing the boot-up program at each node of the network, 

improved method for booting a computer such as to allow ™ ™ upgrade at the server that delivers the particular 

greater flexibility and to permit a computer to selectively component is sufficient. 

boot from either its non-volatile memory unit or from a ln a mosl preferred embodiment, the boot-up procedure 

remote location, such as from a network. includes five stages, namely start-up, discovery, software 

55 download, software initialization and datafill. Several files 

OBJECTS AND STATEMENT OF THE contain instructions indicating to the boot-up program how 

INVENTION to proceed, in particular, where data or software components 

. . » • necessary for the execution of the various stages are located. 

An obiect of the invention is to provide a machine- . C1 , ... . 

, . _ J , . . F . , In addition, a file may also point to an alternate resource 

readable storage medium containing an improved program 6o ^ ' ^ ^ ^ ^ of 

element to boot-up a computer. software component u to be fe inoperau Ve. 

An object of this invention is to provide a novel method Tfac start . up stage initiates the boot-up procedure. The 

for booting-up a computer. CpU c f me computer, upon power-up, begins executing 

Yet another object of the invention is to provide a com- from a boot initiation element a set instructions starting at a 

puter implementing a novel boot-up procedure. 55 particular address of a non- volatile memory. The purpose of 

As embodied and broadly described herein the invention the boot initiation element is to run basic sanity checks to 

provides a machine-readable storage medium containing a determine all the critical components of the computer that 
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are present, run the necessary I/O drivers and communica- As embodied and broadly described herein, the invention 

tion protocols, etc. In other words, the boot initiation ele- also provides a computing apparatus, comprising: 
ment activates software components and sets-up the hard- a processor; 

ware to allow other software elements necessary to complete a memory holding a program element for directing said 

the boot-up procedure to run properly. The boot initiation 5 processor to execute a multi-stage boot-up procedure of 

element interacts with a policy file containing a plurality of ^ computing apparatus, said multi-stage boot-up 

entries that determine specifically how the boot-up proce- procedure including at least two successive stages, said 

dure will be completed. Typically, the policy file that can be program element implementing a boot element for 

either held on a non-volatile memory or be part of the boot initiating one stage of said boot-up procedure; 

initiation element includes one or more pointers specifying 10 ^ . # t . , . . 

, i ■ • i r ^ a data structure in said memory, said data structure 

where a particular information element such as software or • i j* • « * i »• . • ■ • c 

, \. . , it r , including a pointer to a location containing an lnfor- 

data entities are to be acquired. In a most preferred i _ ♦ -j L . i . ui * ■ . ^ 

, ,. A At _ , i mation element, said boot element capable of interact - 

embodiment, the policy tile specifies when the discovery • *u j • i ** i * * «• r 

. . . ¥ j t ti , ,. . J mg with said information element to cause execution of 

stage is to be performed. In short, the discovery stage isa . -j . . j * « ■ ■ j 

. 4 . r \. 1 ... i , , ~ . a- stage of said boot-up procedure following in order 

registration of the computer system with the network. This is . * * . • . u • i *■ i i_i , 

. & , j . u . . said one stage, said pointer being selectively settable to 

involves setting up a data exchange transaction with a given . . t u r r i i f j . 

, . A , ^ . ■ i j it a .* i vomt to either one of a local site and a remote site, 

node in the network to indicate to that node that a particular A r . JL « , v j u • * L - 

4 .... * o . .... As embodied and broadly described herein, the invention 

computer is being boot up. A successful registraUon proce- a]so ides a machme _ r / adable sl0 medium 

dure indtcates that reliable communication with dbe network m fl e , ement fof ^ a ^ 

is likely. Accordingly, software or data elements that may be 20 . J* , „ _ , f ^ • , . 

, / 4 . r V, . 4 . . < , boot-up procedure from power-up, said program element 

needed to complete the boot -up procedure can be acquired , r r t . , . , . £ ... •_, . . 

^ .u * - */*u • * *- j implementing a boot element for initiating said boot-up 

from that source. Otherwise, if the registration procedure is , . , . . , . , , c • * j . 

£■ i ,i . , • ... .. t & . r 4 . . procedure, said boot element capable of interpreting data 

not successnil, the boot initiation element may then revert . , . _ . £1 j .. r . 

i T * i , - * stored in a certain file during execution of said boot-up 

solely to local resources since the network is not accessible. , . , , t . . j- . . LV . 

' t t - tU . 4 . t . A procedure, said boot element providmg means to establish a 

The next step of the boot-up process is the software 25 t ^ t<1 _u' 0 ul,„ r _„ n . 

, 1JA i j , j- . a v data exchange transaction between the computer and a 

download stage that mvolves downloading basic software * •* * r • * r j ci 

r . * i i t. . • ii remote site to verify a vintage of said file. 

from the network or locating that software in a local Tr j . . . . , . 

vc j l ,. £1 ■ 11 Under an example embodying this particular aspect of this 

resource, as specified by the policy file. Typically, the *i_ t_ i f- t_, c • 

c ' . r J , Jr mvention, the boot initiation element is capable of verifying 

software download process is a process whose purpose is to * fl , C1 lL . . . . 

iL i_ « c 4L J tl i- £i me vintage of any one of me ales mat direct the execution 

acquire the bulk of the operating system. The policy file 30 c X — v~l j i *u i- m .t_ ^ 

■c* c , £ f . . T / i or the boot-up procedure, namely the poucy file, the soft- 

specifies from where the files must me acquired. A software , . j C1 . J r\ , 

. r , ., i £i it ware download file, the software initialization file and the 

load may also be present to describe what files need to be j 4 c , T , . -c j • i 

. / ^ f. . . , . datafill file. In short, the verification procedure involves the 

acquired. Once this stage is completed, the necessary . c . t . L1 . 4 - 4 . ^i 

^ , , . C1 & , / lL , steps of commumcatmg any suitable characteristic of the file 

executable files permitting to activate the operating system u ' •* j * c *• •* j * * i_- i_ 1 * 

.... .... . such as its date of creation or its date at which it was last 

will be present in the computer memory. 35 J C j * ■ ." g r * '- , , . 

™ r - A . r a r ii . r ^modified to/aremote reference site, juch as a node m the 

I Tie software initialization step follows next. In essence, . , T fA. ^!l j j !"?t f •* „i_ 

r it . , ■ . , • i- , network. If the file is up to date, the reference site notifies the 

the purpose of this stage is to begin execution of the files u ♦ * *• i « j- i j *u i *-r «i_ 

. j j ■ . • .i _i boot initiation element accordingly, and the latter utilizes the 

acquired during the previous stage in a particular order Ai . . . i.«u 

•c j i_ ^ -.-i. - c, a i ■ . fil e contents to complete the execution of the boot-up 

specified by a software initialization file. At this stage, the , ^ r . , . f tU flJ . , . r 

ci • j- . r t. .1. . i- procedure. On the other hand, if the file is no longer up to 

poucy file indicates from where the software initialization 40 j , , . .A. 

5, . 4 , ... Jrt ... . . , . , -date, and a new version exists, the reference center then 

file is to be obtained. Once this stage is completed, the files . .< ct . . t . , .... 

ft . . , *■ • j j. transmits the new file to the boot initiation element that 

of the operatmg system are active in memory and ready to , C1 , 

t \. . & J .. . , 7 J replaces the old file by the new one. 

execute their respective tasks. A . , , , „ , .... • . 

j . fin * .l. i * .i. l . . . As embodied and broadly described herein the mvention 

The datafill is the last stage of the boot-up procedure and . ., , e ce *• u * j r 

. . , ....... b c £ . j . . also provides a method for effecting a boot-up procedure of 

includes the mtroduction of configuration data mto the 45 , • A 4 . . • ■ a. . <■ 

- . rr . . r .. ^a computer, said method comprising the steps of: 

software instances. Here, data elements necessary for the . r . ' . . , . . 

proper operation of the operating system files are fetched a > f^ng a file m said computer containing data 

from a datafill file and dispatched to the intended recipients. elements, said data elements influencing execution of 

As was the case from the previous stages, the policy file said boot - u P P roccdurc ; 

indicates from where the datafill file is to be obtained. 50 b ) initiating a data exchange transaction with a remote site 

As embodied and broadly described herein, the invention to determine a vintage of said file; and 

also provides a method for effecting a boot-up procedure of c) completing said boot-up procedure. y 
a computer, said boot-up procedure including first and BRIEF DESCRIPTION OF THE DRAWINGS 

second successive stages, said method comprising the steps 

of: 55 These and other features of the present invention will 

a) providing a data stmcture including a pointer to a become i W Ment from the following detailed description 
location containing an information element, said considered in connection w.th the accompanying drawmgs. 
pointer being selectively settable to point to either one 11 15 t0 be ™te™* 0 *. however, that the drawmgs are 
of a local site and a remote site; designed for purposes of illustration only and not as a 

, „ . . , , , an definition of the limits of the invention for which reference 

b) initiating the first step of said boot-up procedure; should bc madc tQ mc appcnding claims 

c) processing said data structure to determine a location of mG x shows a ^^3,^ computing network where the 
said information element; process in accordance with this invention can be imple- 

d) accessing said information element at the location mcnted; 

determined at step c; 65 pic. 2 shows a computing node consistent with the spirit 

e) processing said information element to cause execution of the invention connected via an ATM link to a system 
of said second stage of said boot-up procedure. manager unit; 
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FIG. 3 shows five stages of the booting process in such as Trivial File Transfer Protocol (TFTP). Furthermore, 

accordance with the spirit of the invention; the boot initiation element includes instructions to check for 

FIG. 4 shows flow-charts of the startup stage in accor- a hard drivc ^ a non-volatile RAM module (NVRAM) 206 

dance with the spirit of the invention; ^ ^ interpret the file system 208. Preferably, the 

„ , „,,. . s same algorithm is used whether the computer node is a 

FIG. 5 & 6 shows flow-charts of the discovery stage id Abased or diskless computer. 

accordance with the spirit of the invention; The file system 208 comprises a series of files used in the 

FIG. 7 & 8 show flow-charts of the software download booling process as weU K poimers l0 lhese files t0 allow the 

stage in accordance with the spint of the invention; boot initiation element 202 to access them. In the preferred 

FIG. 9 & 10 show flow-charts of the software initializa- embodiment, the file system includes a policy file, a status 

tion stage in accordance with the spirit of the invention; filCj ^ initialization script file, a datafiU file and software 

FIG. 11 & 12 show flow-charts of the datafill stage in load mes Each of mese files md meir p Urpose ^ be 

accordance with the spirit of the invention; described in detail later in this specification. The structure of 

DESCRIPTION OF A PREFERRED me ** le svstem mav varv across implementations and varia- 

EMBODIMENT 15 t * ons m mc DUmDcr °f or m me structure of the file 

system do not detract from the spirit of the invention. 

The present invention is concerned with a process that Ia the most preferred embodiment of this invention, the 
allows a computer to boot selectively from its own local booting process is divided into five stages, as illustrated in 
non-volatile memory unit or from a network. In the preferred FIG 3j name ly start-up 301, discovery 300, software down- 
embodiment of this invention, when a local non-volatile M load 30 2, software initialization 304 and datafill 306. Each 
memory unit is available, the system uses a policy file stage may be dr i ven e i t h er from the local hard drive (or 
located in the non-volatile memory unit. The policy file NVRAM) or from the system manager on the network 
directs each stage of the booting process independently, depending on the instructions in a policy file, 
which allows for greater flexibility during the booting pro- fa a prefcrred embodimenl the policy file is a file com- 
cess. Preferably, the policy file is easily modified to reflect ^ prising a sct of CQtrics ^ CQntrol thc booting proccss It ^ 
the system changing requirements. Furthermore, failure located - n ^ hafd dfive Qr Qlher Qon . volatile memory ^ 
recovery mechanisms allow the computer to revert to an md & accessible ^ thc filing systcm 2 Q8. The main 
alternative booting scheme. For example, in the case where advaDt age of having the policy file in the hard drive is that 
a local non-volatile memory unit is in failure or not me polky file may be casily rcK;onfigurcd by the network 
available, me computer can wait for the system manager to 3Q m according to the changing requirements of the 
send the booting mstructions through the network l^ese net work. Alternatively, the pohcy file may be part of the boot 
features and others will become apparent following the e]emeQt 202 A role of the }{ file fc tQ ^ 
desenpuon in the sections that follow. if software or data entities are to be acquired from the remote 

Computers that may make use of the booting method in system manager through the network or from a local 

accordance with this invention may be used in stand-alone 35 memory unit such as a hard drive or an NVRAM unit, 

mode or be of a distributed nature, as shown in FIG. 1. These Before eacn stage m tne booting process shown in FIG. 3, 

machines, herein designated as nodes, may reside in geo- the policy file is examined in order to determine if the stage 

graphically remote locations and communicate using a set of must be run locally or remotely. 

predefined protocols. Protocols such as TCP/IP, client/server ^ first stage in FIG . 3? the start . up stage 301) irlvolves 

architecture and message passing are all possible methods of 40 me CPU of me computer upon power-up to begin executing 

achievmg a distributed computing environment. For more a boot vitiation element. The instructions in the boot 

information on distributed processing, the reader is invited initiation element are performed starting at a particular 

to consult Operating Systems by William Stallings, Prentice address of a non _ volat i le memory unit such as a ROM unit 

Hall 2 n edition 1995. The text of this document is included or other suitable devices ^ purpose of ihe boQt 

hereby by reference. 45 c i emcnt is to run basic sanity checks to determine all the 

In the preferred embodiment of this invention, as illus- critical components of the computer that are present, run the 

trated in FIG. 2, the computing node to be booted 201, herein necessary I/O drivers and communication protocols, etc. In 

referred to as the new computing node, is in a computer other words, the boot initiation element activates software 

network comprising a system manager entity 200. components and sets-up the hardware to allow other soft- 

Preferably, the new computing node 201 and the node 50 ware elements necessary to complete the boot-up procedure 

including the system manager 203 communicate through an to run properly. In a typical flow of events, as shown in FIG. 

ATM link or other network connection. The new computing 4, when the power is first initialized in the computer, the 

node comprises a boot initiation element software module boot initiation element code begins to execute and searches 

202 and may include a hard disk or a non-volatile RAM for a hard drive and a non-volatile memory unit 400. 

(NVRAM) unit 206. 55 Condition 402 is checked, and if neither a hard drive nor a 

The boot initiation element 202 is the first piece of code non-volatile memory unit are found, the boot initiation 

that is executed when the computer powers on. Preferably, element using the .ATM driver code initiates the discovery 

the code begins at an address of the memory that is the proccss 406 by sending a registration message to the system 

default address loaded in the code segment of the CPU upon manager. Following this, the computer waits for a remo te 

power-up. Thus, when the CPU is energized and becomes 60 joot 408 and for software to be received from the network, 

operational it begins executing the instructions of the boot If condition 402 is answered in the negative, condition 410 

initiation element. The boot initiation element includes is checked. If a hard disk is found then it is searched 412 for 

software allowing the computer to perform a network boot a file system containing the files required for booting, 

namely an ATM driver allowing it to communicate with the Condition 414 is answered in the positive if a valid file 

system manager, software to run basic sanity checks on the 65 system is found and the computer will boot from the hard 

system, software providing a simple communication pro to- disk 416. If conditions 410 or 414 are answered in the 

col and software to download information from the network negative, namely if there is no hard disk or if the hard disk 
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does not contain a valid file system, the NVRAM is searched instructions, a verification operation is performed, herein 

for the software required 418 located at a well-known referred to as checking the vintage of the file, in order to 

location. If the software is not found as checked by condition determine if the file contains the current version of the 

420, the boot initiation clement, using the ATM driver code, instructions. The general idea in the validation involves 

initiates the discovery process 406 by sending a registration 5 ^comparing the date of the policy file in the new computer 

message to the system manager. Following this, the com- the date of ^ P olic y file m me svstem manager. If the 

puter waits for a remote boot 408 and for software to be file bem S verified is up to date, the system manager sends an 

received from the network. However, if condition 420 is a PP ro ^ messa 8 e ' **** m mana ^ r f nds f° 

answered in the positive, the computer will boot from the "p-to-date votot of the file The first step m checking the 

xnm a x x ni *u r *u i t • . .~y v M ta g c or the policy file involves extracting the date of the 

NVRAM 422. Once the source of the booting process has i(r . K J . fftA Tr , 

, . . . . . , • r^r^ r policy file in the new computer 600. If the discovery has 

been selected, booting can begin as shown m FIG. 5. £een done, condition 602 is answered in the positive and the 

The following stage, the discovery stage 300, involves the new computer sends a message to the system manager 

new computer registering with the system manager through containing the date of the policy file 604. If the date of the 

the network. Essentially, using the ATM driver, the new ^policy file is valid, condition 606 is answered in the positive 

computer sends messages to the system manager identifying 15 and the system manager sends a message to proceed 610, 

its presence and its location. The system manager typically and the new computer then considers the policy file valid 

registers the new computer node and sends an acknowledge- 612. If the discovery has not been done, condition 602 is 

ment message. The discovery stage can be performed at any answered in the negative and the policy file is also assumed 

time during the booting process. For example, if the soft- y to be valid 612. If the date of the policy file is not valid, 

ware download 302 and initialization stage 304 are to be 20 condition 606 is answered in the negative and the system 

performed locally (from the hard drive or from the manager sends a message to the new computer along with a 

NVRAM) and the datafill stage 306 needs to be done from new policy file 608, In the case where a new policy file is 

the network, the discovery may be diferred until the datafill sent, the system starts over (tag A) by examining the 

stage is ready to begin since the system manager doesn't discovery convention. In the case where the policy file was 

need to know where the new computer is located until it 25 valid, the system proceeds to the software download stage 

must send data or messages to it. In a typical flow of events, 302 (tag C). 

as shown in FIG. 5, the interpreter in the boot initiation The software download stage 302 involves downloading 

element examines the policy file 500 and determines if basic software from the network. In the case where the 

discovery must take place immediately. In the preferred system has a hard drive and is to obtain the software locally, 

embodiment of this invention, the policy file contains 30 this stage may involve locating the software in the local 

instructions of the form: storage device, with the use of a load description file 



Disco very {BEFOREDISKBOOT | AFTER DISKBOOT j AFTERINITSCRIPT | 

AFTER DATAFILL} 
Policy File Vintage{CHECK|NO CHECK} 



where the vertical bars indicate that only one of the options d0 
needs to be specified. If condition 502 is answered in the 
positive, the discovery is to be performed immediately. The 
boot initiation element then sends a discovery message 504 
to the system manager. Condition 506 verifies if an acknowl- 
edgement message is received from the system manager 45 
indicating a successful discovery. If condition 506 is 
answered in the affirmative, an entry is made to a status file 
508 indicating that the discovery is done. If either condition 
502 or condition 506 is answered in the negative, an entry 
is made to a status file 510 indicating that the discovery is 50 
not done. The status file is used to maintain status informa- 
tion about the booting process including which stages have 
been performed and whether or not they were successful. 
The network manager can examine this file in order to obtain 
a "footprint" of the cause of an unexpected failure. It can 55 
also be used to verify that all the stages in the booting 
process were executed as specified in the policy file. In 
essence, the status file is there to keep a log of the booting 
process and is not critical in the booting process. Therefore 
the absence of a status file in an embodiment of this 60 
invention does not detract from the spirit of this invention. 
In addition to indicating if a booting stage was successful, 
entries in the status file may also include the number of time 
a certain stage has failed and whether the vintage of a given 
file has been verified. After steps 510 and 508 we proceed in 65 
validating the policy file as shown in FIG. 6. Preferably, 
every time a new file is accessed in order to obtain booting 



identifying the software image on the computer. Preferably 
the software downloaded includes software to download yet 
more software. The software image may include the basic 
operating system and a node management module. In the 
preferred embodiment the software load is a single execut- 
able file. Other types of files may constitute a software load 
without detracting from the spirit of the invention. The 
software load may also include a load description file that 
describes which software runs on a given node. Preferably, 
the load description file is small so that it may be easily 
transferred to the system manager for a vintage check. 
Optionally, more than one load image may be present in the 
software load files to accommodate operating systems with 
multiple address space such as UNIX. For these operating 
systems, separate software load files may be started in 
different address spaces. In a typical interaction as shown in 
FIG. 7, the load convention is obtained from the policy file 
700 that indicates if the software load is to be obtained 
remotely or locally. Preferably, computers with local hard- 
drives or NVRAMs boot locally in order to improve the 
speed of the booting process and the system manager only 
participates in the process if needed. If the software load is 
to be obtained locally, then condition 702 is answered in the 
negative. Preferably, a failure recovery mechanism is 
present which allows the computer to boot from an alterna- 
tive memory source in the case where the preferred source 
designated in the policy file is unavailable. For example, if 
the policy file requires software or data to be obtained from 
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a remote system manager and the latter is not accessible for 
whatever reason, the computer will boot from the local hard 
drive or NVRAM if the required software or data is valid 
and present. The converse is also possible, namely if the 
policy file requires software or data to be obtained from the 5 
local hard drive and the latter is not accessible for whatever 
reason, the computer will boot from the system manager if 
the required software or data is valid and present. In the case 
where both the hard drive (or NVRAM) and remote system 
manager are unavailable, the computer will not boot. 10 
Therefore, the computer keeps track of the number of 
failures. If the number of failures is below a pre-determined 
allowed number of failures, condition 704 is answered in the 
negative and the software load will be obtained from the 
hard disk or NVRAM. Preferably, the required information 15 
about the software load is located in a load description file 
that indicates which files are in the software load and what 
is their vintage. The policy file is then examined to deter- 
mine if the vintage of the load file must be verified before 
proceeding. If the vintage of the load files must not be 20 
checked, condition 706 is answered in the negative and the 
computer proceeds in booting from the local hard-drive (or 
NVRAM) 714. Booting from the hard drive may include 
searching for predetermined files. Condition 716 verifies if 
the booting was a success. If the boot was a success, step 720 25 
resets the number of boot failures to zero and proceeds to the 
software initialization stage (tag E). If the boot wasn't a 
success, condition 716 is answered in the negative and the 
number of failures is incremented 718. Condition 704 is then 
re-evaluated. If the vintage of the load file must be checked, 30 
condition 706 is answered in the positive and the computer 
proceeds in verifying the date of the load file. If the 
discovery stage has already been done, condition 708 is 
answered in the positive and the date of the load file is sent 
to the system manager 710. At condition 712 the system 35 
manager evaluates if the load file for the computer is the 
most up-to-date file. If the date of the load file is accepted, 
condition 712 is answered in the positive and the local boot 
can begin at step 714. If at condition 708 the discovery stage 
has not taken place, the condition is answered in the negative 40 
and the load file is assumed to be valid and allows the local 
boot to begin at step 714. The node proceeds in booting from 
the network (tag D) in three cases. The first case occurs if the 
policy file indicates that the software load must be obtained 
from the network causing condition 702 to be answered in 45 
the positive. The second case occurs if the local booting has 
failed more than a pre-determined number of times causing 
condition 704 to be answered in the positive. And finally, the 
third case occurs if the system manager did not accept the 
date of the load file causing condition 712 to be answered in 50 
the negative. The network booting procedure is shown in the 
flow chart of FIG. 8. Condition 800 is answered in the 
positive if the status file indicates that the discovery has been 
done. The computer then waits for the system manager to 
send packets 802 containing the software load. If the soft- 55 
ware load is a success, condition 804 is answered in the 
positive, the status file reflects that the software load stage 
was successful and the computer proceeds to the software 
initialization stage (tag E). However, the software load stage 
may fail for a number of reasons. For example, the system 60 
manager may be unavailable, the packets may have gotten 
lost, or the connection may have been broken. If the software 
load stage fails, condition 804 is answered in the negative. 
The computer verifies if the number of failures exceeds the 
number of failures permitted. If it does, condition 850 is 65 
answered in the positive and the process is aborted 806. 
However, if the number of failures is less than the maximum 
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number permitted, condition 850 is answered in the negative 
and the computer attempts a local software load stage 852 
starting at stage 706 on FIG. 7. If at condition 800 the 
discovery has not been done, the computer begins the 
discovery process by sending discovery messages 808 
across the network to the system manager. If the discovery 
is successful, condition 810 is answered in the positive and 
an entry is made to the status file to indicate that the 
discovery has been done. The computer then waits for the 
system manager to send packets 802 containing file load 
information. In the event that the discovery fails, condition 
810 is answered in the negative and an entry is made to the 
status file to indicate that the discovery was not done 814. 
The process then proceeds to condition 850. 

The following stage, the software initialization stage 304, 
involves starting and initializing part of the software 
received or located in the software download stage 302. 
Software initialization involves executing code, preferably a 
script file, which instructs the computer to start a set of 
programs or processes. The preferred embodiment of this 
invention uses an initialization script file. This file includes 
a set of commands to start or create software instances on the 
computer. In its simplest form, the initialization script file is 
a sequence of startO and create() messages sent to different 
components of the software load. In a typical interaction as 
shown in FIG. 9, the software initialization convention is 
obtained from the policy file 900 that indicates if the 
initialization script file is to be obtained remotely or locally. 
If the initialization script is to be obtained locally, then 
condition 902 is answered in the negative. The computer 
then checks how many times the initialization procedure has 
failed. If the number of failures is below a pre-determined 
allowed number of failures, condition 904 is answered in the 
negative and the initialization script will be obtained from 
the hard disk or NVRAM. The policy file is then examined 
to determine if the vintage of the initialization script file 
must be verified before proceeding. If the vintage of the 
initialization script file does not need to be checked, condi- 
tion 906 is answered in the negative and the computer 
proceeds in executing the initialization script from the local 
hard-drive (or NVRAM) 914. Condition 916 verifies if the 
initialization was a success. If the boot was a success, step 
918 resets the number of initialization failures to zero and 
proceeds to the datafill stage (tag G). If the initialization was 
not a success, condition 916 is answered in the negative and 
the number of failures is incremented 920. Condition 904 is 
then re -evaluated. Returning to condition 906, if the vintage 
of the initialization script file must be checked, condition 
906 is answered in the positive and the computer proceeds 
in verifying the date of the file. If the discovery stage has 
already been done, condition 908 is answered in the positive 
and the date of the initialization script file is sent to the 
system manager 910. At condition 912 the system manager 
evaluates if the initialization script file for the computer is 
the most up-to-date file. If the date of the initialization script 
file is accepted, condition 912 is answered in the positive 
and the local initialization can begin at step 914. If at 
condition 908 the discovery stage has not taken place, the 
condition is answered in the negative and the initialization 
script file is assumed to be valid and allows the local 
initialization to begin at step 914. The node proceeds in 
initializing from the network (tag F) in three cases. The first 
case occurs if the policy file indicates that the initialization 
script file must be obtained from the network causing 
condition 902 to be answered in the positive. The second 
case occurs if the local initialization has failed more than a 
pre-determined number of times causing condition 904 to be 
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answered in the positive. The third case occurs if the system 
manager did not accept the date of the initialization script 
file causing condition 912 to be answered in the negative. 
The network initialization procedure is shown in the flow 
chart of FIG. 10. Condition 1000 is answered in the positive s 
if the status file indicates that the discovery has been done. 
The computer then waits for the system manager to send 
packets 1002 containing the initialization script and then 
executes the script. If the initialization is a success, condi- 
tion 1004 is answered in the positive and the computer 10 
proceeds to the datafill stage (tag G). However, the initial- 
ization may fail for a number of reasons. For example, the 
system manager may be unavailable, the packets may have 
gotten lost, or the connection may have been broken. If the 
initialization fails, condition 1004 is answered in the nega- 35 
five. If the software load stage fails, condition 804 is 
answered in the negative. The computer then verifies if the 
number of failures exceeds the number of failures permitted. 
If it does, condition 1050 is answered in the positive and the 
process is aborted 1006. However, if the number of failures 20 
is less than the maximum number permitted, condition 1050 
is answered in the negative and the computer attempts a 
local software initialization 1052 starting at stage 906 on 
FIG. 9. If at condition 1000 the discovery has not been done, 
the computer begins the discovery process by sending 25 
discovery messages 1008 across the network to the system 
manager. If the discovery is successful, condition 1010 is 
answered in the positive and an entry is made to the status 
file to indicate that the discovery has been done. The 
computer then waits for the system manager to send packets 30 
1002 containing the initialization script and then executes 
the script. In the event that the discovery fails, condition 
1010 is answered in the negative and an entry is made to the 
status file to indicate that the discovery was not done 1014. 
The process then proceeds to condition 1050. 35 

Once the software instances have been started or created 
through the commands of the initialization script file, the 
datafill stage 306 involves loading the data into the software 
instances initialized by the software initialization stage 304. 
In the preferred embodiment, a datafill file contains a 40 
sequence of instructions, herein referred to as messages, 
which direct the computer as to how to start the software 
instances. In a typical interaction as shown in FIG. 11, the 
datafill convention is obtained from the policy file 1100 that 
indicates if the datafill file is to be obtained remotely or 45 
locally. If the datafill file is to be obtained locally, then 
condition 1102 is answered in the negative. The computer 
then checks how many times the datafill procedure has 
failed. If the number of failures is below a pre-determined 
allowed number of failures, condition 1104 is answered in 50 
the negative and the datafill file will be obtained from the 
hard disk or NVRAM. The policy file is then examined to 
determine if the vintage of the datafill file must be verified 
before proceeding. If the vintage of the datafill file does not 
need to be checked, condition 1106 is answered in the 55 
negative and the computer proceeds in executing the datafill 
file code from the local hard -drive (or NVRAM) 1114. 
Condition 1116 verifies if the datafill was a success. If the 
datafill was a success, step 1118 resets the number of datafill 
failures to zero and the computer initialization is done 1120 60 
successfully. If the datafill was not a success, condition 1116 
is answered in the negative and the number of failures is 
incremented 1122. Condition 1104 is then re-evaluated. 
Returning to condition 1106, if the vintage of the datafill file 
must be checked, condition 1106 is answered in the positive 65 
and the computer proceeds in verifying the date of the file. 
If the discovery stage has already been done, condition 1108 
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is answered in the positive and the date of the datafill file is 
sent to the system manager 1110. At condition 1112 the 
system manager evaluates if the datafill file for the computer 
is the most up-to-date file. If the date of the datafill file is 
accepted, condition 1112 is answered in the positive and the 
local datafill can begin at step 1114. If at condition 1108 the 
discovery stage has not taken place, the condition is 
answered in the negative and the datafill file is assumed to 
be valid, the system is allowed to begin local datafill at step 
1114. The computer node obtains the datafill file from the 
network (tag H) in three cases. The first occurs if the policy 
file indicates that the datafill file must be obtained from the 
network causing condition 1102 to be answered in the 
positive. The second case occurs if the local datafill has 
failed more than a predetermined number of times causing 
condition 1104 to be answered in the positive. The third case 
occurs if the system manager did not accept the date of the 
datafill file causing condition 1112 to be answered in the 
negative. The network datafill procedure is shown in the 
flow chart of FIG. 12. Condition 1200 is answered in the 
positive if the status file indicates that the discovery has been 
done. The computer then waits for the system manager to 
send packets 1202 containing the datafill file and then 
executes the code. If the datafill is a success, condition 1204 
is answered in the positive and the computer has finished 
booting. However, the remote datafill operation may fail for 
a number of reasons. For example, the system manager may 
be unavailable, the packets may have gotten lost or the 
connection may have been broken. If the datafill fails, 
condition 1204 is answered in the negative. The computer 
then verifies if the number of failures exceeds the number of 
failures permitted. If it does, condition 1250 is answered in 
the positive and the process is aborted 1216. However, if the 
number of failures is less than the maximum number 
permitted, condition 1250 is answered in the negative and 
the computer attempts a local datafill stage 1252 starting at 
stage 1106 on FIG. 11. If at condition 1200 the discovery has 
not been done, the computer begins the discovery process by 
sending discovery messages 1208 across the network to the 
system manager. If the discovery is successful, condition 
1210 is answered in the positive and an entry is made to the 
status file to indicate that the discovery has been done. The 
computer then waits for the system manager to send packets 
1202 containing the datafill file and then executes the code. 
In the event that the discovery fails, condition 1210 is 
answered in the negative and an entry is made to the status 
file to indicate that the discovery was not done 1214. The 
process then proceeds to condition 1250. 

Although the present invention has been described in 
considerable detail with reference to certain preferred 
embodiments thereof, variations and refinements are pos- 
sible without departing from the spirit of the invention. 
Therefore, the scope of the invention should be limited only 
by the appended claims and their equivalents. 

What is claimed is: 

1. A machine-readable storage medium containing a pro- 
gram element for directing a computer to effect a multi-stage 
boot-up procedure from power-up, said multi-stage boot-up 
procedure including a first stage and a plurality of successive 
stages following said first stage, the implementation of the 
stages subsequent to the first stage being effected by execut- 
ing respective program code units, said program element 
including: 

a boot initiation program module for execution by the 
computer to implement a first stage of said boot-up 
procedure; 
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a policy file operative for directing execution of stages 
subsequent to the first stage of said boot-up procedure, 
said policy file having a plurality of entries, each entry 
pointing to a location containing a program code unit 
suitable for execution by the computer to implement a 5 
respective stage of said multi-stage boot -up procedure, 
at least one entry pointing toward a location containing 
a first program code unit residing locally at the com- 
puter and at least another entry pointing toward a 
location containing a second program code unit resid- 10 
ing at a site remote from the computer, the first program 
code unit being associated with a stage of the boot-up 
procedure that occurs subsequently to the first stage, 
the first program code unit residing locally at the 
computer prior to the execution of the first stage. 15 

2. A machine-readable storage medium as defined in 
claim 1, wherein said boot initiation program module is 
capable of interacting with at least one of entry in said policy 
file. 

3. A machine -readable storage medium as defined in 20 
claim 2, wherein said boot initiation program module is 
operative for searching locally at the computer for a memory 
unit. 

4. A machine -readable storage medium as defined in 
claim 3, wherein said boot initiation program module is 25 
operative for searching the memory unit for program code 
units. 

5. A machine -readable storage medium as defined in 
claim 2, wherein said boot initiation program module is 
operative for establishing a data exchange transaction 30 
between the computer and the site remote from the com- 
puter. 

6. A machine -readable storage medium as defined io 
claim 5, wherein said policy file includes a first entry, said 
boot initiation program module being operative to process 35 
the first entry to issue a message to the site remote from the 
computer. 

7. A machine -readable storage medium as defined io 
claim 6, wherein said policy file includes a second entry 
indicative of a location where program code units associated 40 
to a given stage reside. 

8. A machine-readable storage medium as defined in 
claim 7, wherein said boot initiation program module is 
operative for processing said second entry to determine the 
location where the program code unit associated to a given 45 
stage resides. 

9. A machine -readable storage medium as defined in 
claim 8, wherein upon occurrence of a failure of an attempt 
for processing the program code unit at a location pointed to 
by said second entry, said boot initiation program module is 50 
operative to process a program code unit at another location. 

10. A machine-readable storage medium as defined in 
claim 9, wherein said second entry points locally at the 
computer and said another location is a site remote from the 
computer. 55 

11. A machine-readable storage medium as defined in 
claim 9, wherein said second entry points toward a site 
remote from the computer and said another location is 
locally at the computer 

12. A machine-readable storage medium as defined in 60 
claim 5, wherein said boot initiation program module is 
operative for establishing a data exchange transaction to 
verify a vintage associated to said policy file, the vintage 
comprising at least one data element indicative of a time 
characteristic. 65 

13. A machine-readable storage medium as defined in 
claim 2, wherein said policy file is a script file, said script file 



including a plurality of entries, at least one of said entries 
directing said boot initiation program module to execute a 
given program code unit. 

14. A machine-readable storage medium as defined in 
claim 13, wherein said given program code unit is a software 
download file. 

15. A machine-readable storage medium as defined in 
claim 13, wherein said given program code unit is a datafill 
file, sa datafill file including a plurality of entries, at least one 
of said cn tries directing said computer to transfer data to a 
certain file other than said datafill file. 

16. A method for effecting a boot -up procedure of a 
computer, said boot-up procedure including a first stage and 
a plurality of successive stages following said first stage, the 
stages subsequent to the first stage being effected by execut- 
ing respective program code units, said method comprising 
the steps of: 

a) providing a policy file having a plurality of entries, 
each entry pointing to a location containing a program 
code unit suitable for execution by the computer to 
implement a respective stage of said boot-up 
procedure, at least one entry pointing toward a location 
containing a first program code unit residing locally at 
the computer and at least another entry pointing toward 
a location containing a second program code unit 
residing at a site remote from the computer, the first 
program code unit being associated with a stage of the 
boot-up procedure that occurs subsequently to the first 
stage, the first program code unit residing locally at the 
computer prior to the execution of the first stage; 

b) initiating a first stage of said boot-up procedure; 

c) processing said policy file to determine a location 
associated to a given program code unit for effecting a 
certain stage subsequent to the first stage; 

d) accessing said given program code unit at the location 
determined at step c); 

e) processing said given program code unit to cause 
execution of the certain stage of said boot-up proce- 
dure. 

17. A method as defined in claim 16, wherein at least one 
entry in said policy file influences the execution of a stage 
subsequent to the first stage. 

18. A method as defined in claim 17, comprising the step 
of searching locally for a memory unit. 

19. A method as defined in claim 18, comprising the step 
of searching said memory unit for program code units. 

20. A method as defined in claim 17, comprising the step 
of establishing a data exchange transaction between the 
computer and the site remote from the computer during 
execution of either stage of the plurality of stages of said 
boot-up procedure. 

21. A method as defined in claim 20, wherein said policy 
file includes an entry indicative of a location where a given 
program code unit resides. 

22. A method as defined in claim 21, comprising the step 
of processing said entry to determine the location where said 
given program code unit resides. 

23. A method as defined in claim 22, comprising the step 
of attempting to process said given program code unit at the 
location pointed to by said second entry, upon occurrence of 
a failure of an attempt to process said given program code 
unit, attempting to process a program code unit at an another 
location. 

24. A method as defined in claim 23, wherein said second 
entry points locally at the computer and said another loca- 
tion is a site remote from the computer. 
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25. A method as defined in claim 23, wherein said second 
entry points toward a site remote from the computer and said 
another Location is a local site. 

26. A method as defined in claim 20, comprising the step 
of establishing a data exchange transaction between the 5 
computer and the site remote from the computer to verify a 
vintage associated to said policy file, the vintage comprising 

at least one data element indicative of a time characteristic. 

27. A computing apparatus, comprising: 

a processor; 10 
a memory holding a program element for directing said 
processor to execute a multi-stage boot-up procedure of 
said computing apparatus, said multi-stage boot-up 
procedure including a first stage and a plurality of 
successive stages subsequent to the first stage, the 15 
implementation of the stages subsequent to the first 
stage being effected by executing respective program 
code units, said program element implementing a boot 
initiation program module for execution by the com- 



>1 Bl 

16 

puling apparatus to implement the first stage of said 
boot-up procedure; 
a policy file in said memory, said policy file having a 
plurality of entries, each entry pointing to a location 
containing a program code unit suitable for execution 
by the computer to implement a respective stage of said 
multi-stage boot-up procedure, at least one entry point- 
ing toward a Location containing a first program code 
unit residing locally at the computer and at least 
another entry pointing toward a location containing a 
second program code unit residing at a site remote from 
the computer, the first program code unit being asso- 
ciated with a stage of the boot-up procedure that occurs 
subsequently to the first stage, the first program code 
unit residing locally at the computer prior to the execu- 
tion of the first stage. 

* + * + + 
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ABSTRACT 



A system for loading upgraded, that is, new boot code and/or 
main firm ware has a programmable memory that has two 
boot code regions. One of the regions holds the active boot 
code while the other region holds the inactive boot code. 
During a boot code upgrade, the boot code in the inactive 
region, is under control of the boot code in the active region, 
replaced with the new boot code. Once the replacement 
process is verified as having been successful and the vector 
table in the new boot code is copied to the processor vector 
table in the memory, the processor can be reset so that the 
new boot code becomes the active boot code and the 
previously active boot code becomes the inactive boot code. 

34 Claims, 4 Drawing Sheets 
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METHOD AND APPARATUS FOR 
UPGRADING FIRMWARE BOOT AND MAIN 
CODES IN A PROGRAMMABLE MEMORY 

1 . FIELD OF THE INVENTION s 

This invention relates to the upgrading of either or both of 
the firmware boot and main codes in a programmable 
memory. 

2. DESCRIPTION OF THE PRIOR ART 10 

Programmable memory and microprocessors are used in 
many devices. One such device is a remote handheld ter- 
minal that is used by technicians in the process industries for 
process control system configuration, monitoring, tuning is 
and diagnostics. The handheld terminal has firmware therein 
stored in the programmable memory. The firmware includes 
the boot code and the main code. The main code is used for 
the regular operation of the handheld terminal. 

Sometimes it is necessary to upgrade the firmware in the 20 
remote handheld terminal. A need for upgrading the boot 
code might arise when the functionality of that code is 
enhanced. The main firmware will be upgraded whenever 
the normal functionality of the handheld terminal has to be 
enhanced or modified. Therefore, the upgrade of firmware in 25 
the remote handheld terminal may include an enhancement 
of the functionality of the terminal. In that instance, the 
firmware upgrading technique must allow for a flexible size 
and location remapping of the boot and main firmware codes 
without any need for hardware changes. 30 

One technique that is now used to upgrade the firmware 
of a remote handheld terminal is to open the terminal and 
insert programmable memory with the new firmware therein 
in place of the programmable memory in the terminal. As 
can be appreciated, this technique involves both cost and 35 
delay in upgrading the terminal to the new firmware as 
programmable memory must first be programmed with the 
new firmware and then delivered to the sites where the 
terminals are used. As can further be appreciated, this 
technique usually requires an instrument technician or other 40 
person with knowledge of electronic circuitry to open and 
replace the programmable memory, and may result in dam- 
age to the handheld terminal during the replacement process. 

U.S. Pat. Nos. 5,432,927 and 5,568,641 describe other 45 
techniques that may be used to upgrade the boot firmware in 
a remote handheld terminal. Both of these techniques rely on 
hardware assisted mapping of the boot code addresses. 
Therefore, neither of these techniques would allow the size 
and location of the boot codes in the processor address map 
of the handheld terminal to be changed without a hardware 
change. As is described above, such a change is not desirable 
as it requires that the terminal be opened. 

SUMMARY OF THE INVENTION 

55 

A system for providing new boot code for a processor. 

The system has a writable non-volatile memory. The 
memory has one region that has active non-write protected 
boot code therein which has the functionality to allow an 
instrument containing the memory to communicate with a 60 
process control; and another region that has inactive boot 
non-write protected code therein which is a functional 
equivalent of the active boot code. The system also has a 
source of the new boot code; and a processor and associated 
electronics that is under the control of the active boot code 65 
for replacing the inactive boot code with the new boot code 
from the source. 
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A system for providing new boot code for a processor. The 
system has a writable non-volatile memory. The memory has 
one region that has active non-write protected boot code 
therein which has the functionality to allow an instrument 
containing the memory to communicate with a process 
control; and another region that has inactive non-write 
protected boot code therein. The system also has a source of 
the new boot code connected to the processor. The processor 
operating under control of the active boot code replaces the 
inactive boot code with the new boot code from the source. 

A method of providing new boot code for a processor. The 
method has a step of providing a writable non-volatile 
memory having one region having active non-write pro- 
tected boot code for the processor therein which has the 
functionality to allow an instrument containing the memory 
to communicate with a process control and another region 
having inactive non-write protected boot code for the pro- 
cessor therein which is a functional equivalent of the active 
boot code. The method also has the steps of connecting a 
source of new boot code to the processor; transmitting the 
new boot code from the source to the processor; and writing 
under control of the active boot code the new boot code to 
the another region to thereby replace the inactive boot code. 

In a device that has a processor a method of providing 
new boot code for the processor. The method has the step of 
providing in the device a writable non-volatile memory 
having one region having active non-write protected boot 
code for the processor therein which has the functionality to 
allow an instrument containing the memory to communicate 
with a process control and another region having inactive 
non-write protected boot code for the processor therein 
which is a functional equivalent of the active boot code. The 
method also has the steps of connecting a source of new boot 
code to the processor; transmitting the new boot code from 
the source to the processor; and writing under control of the 
active boot code the new boot code to the another region to 
thereby replace the inactive boot code. 

A system for providing new boot code for a processor in 
a device. The system has a writable non-volatile memory in 
the device. The memory has one region that has active 
non-write protected boot code therein which has the func- 
tionality to allow an instrument containing the memory to 
communicate with a process control; and another region that 
has inactive non-write protected boot code therein which is 
a functional equivalent of the active boot code. The system 
also has a means for connecting a source of the new boot 
code to the device; and a means including the processor and 
under control of the active boot code for replacing the 
inactive boot code with the new boot code from the source. 

A method for upgrading the boot code in an instrument 
that has a non-volatile memory. The memory has a first boot 
code block having a vector table and a boot code area and 
a second boot code block having a vector table and a boot 
code area. Each of the first and the second boot code areas 
having boot code in them. The method has the step of 
determining from a processor vector table stored in the 
non-volatile memory which of the first and second boot code 
blocks is then currently active. The method also has the step 
of writing the upgraded boot code and an associated vector 
table into the boot code area and vector table area, 
respectively, of that one of the first and the second boot code 
blocks which is not then currently active. The method has 
the further step of determining the successful transfer of the 
upgraded boot code and the associated vector table to that 
one of the first and the second boot code blocks which is not 
then currently active. The method also has the further steps 
of causing the then currently active boot code to overwrite 
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the processor vector table with the vector table associated 
with the upgraded boot code; and resetting the instrument 
upon verification that the overwriting of the processor vector 
table has occurred so that the upgraded boot code becomes 
the currently active boot code for the instrument after s 
resetting has occurred. 

A method for upgrading the boot code in an instrument 
having a non-volatile memory. The memory has a first boot 
code block having a vector table and a boot code area with 
currently active boot code and a second boot code block 1° 
having a vector table and a boot code area with currently 
inactive boot code. The method has the step of writing the 
upgraded boot code and an associated vector table into the 
boot code area and vector table area, respectively, of the 
second boot code block. The method also has the step of 15 
determining the successful transfer of the upgraded boot 
code and the associated vector (able to the second boot code 
block. The method has the further step of causing the then 
active boot code to overwrite the processor vector table with 
the associated upgraded vector table. The method also has 2 0 
the further step if resetting the instrument upon verification 
that the overwriting of the processor vector tabic has 
occurred to thereby make the upgraded boot code the active 
boot code for the instrument after the resetting has occurred. 

A method for operating an instrument having a non- 25 
volatile memory. The memory has a first boot code block 
having a vector table and a boot code area with currently 
active boot code and a second boot code block having a 
vector table and a boot code area with currently inactive boot 
code. The method has the step of using the currently active 30 
boot code to operate the instrument. The method also has the 
step of upgrading the currently inactive boot code. The 
upgrading step has the steps of: 

(i) writing the upgraded boot code and an associated 
vector table into the boot code area and vector table 35 
area, respectively, of the second boot code block; 

(ii) determining the successful transfer of the upgraded 
boot code and the associated vector table to the second 
boot code block; 

40 

(iii) causing the active boot code to overwrite the proces- 
sor vector table with the associated upgraded vector 
table; and 

(iv) resetting the instrument upon verification that the 
overwriting of the processor vector table has occurred 45 
to thereby make the upgraded boot code the active boot 
code for the instrument after the resetting has occurred. 

A system for upgrading boot code in a non -volatile 
memory of an instrument. The system has a processing 
device having the upgraded boot code. The instrument is 50 
connected to the processing device for receiving the 
upgraded boot code from the processing device. The instru- 
ment non-volatile memory has: 

(i) a first boot code block haviog a vector table and a boot 
code area with currently active boot code therein; 55 

(ii) a second boot code block having a vector table and a 
boot code area with currently inactive boot code 
therein; and 

(iii) a processor vector table stored therein. 

The processing device causes the instrument to overwrite the 60 
currently inactive boot code with the upgraded boot code 
and the vector table of the second boot code block with a 
vector table associated with the upgraded boot code, and the 
currently active boot code to overwrite the processor vector 
table with the associated upgraded vector table. The pro- 65 
cessing device also causes the currently active boot code to 
reset the instrument when the overwriting of the processor 
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vector table has occurred to thereby make the upgraded boot 
code the active boot code for the instrument after the 
resetting has occurred. 

A method for upgrading boot code in a non-volatile 
memory of an instrument. The memory has a first boot code 
block having a vector table and a boot code area with 
currently active boot code therein and a second boot code 
block having a vector table and a boot code area with 
currently inactive boot code therein. The method has the step 
of connecting the instrument to a processing device for 
receiving the upgraded boot code from the processing 
device. The method also has the step of upgrading the 
currently inactive boot code. This step has the steps of: 

(i) writing the upgraded boot code and an associated 
vector table into the boot code area and vector table 
area, respectively, of the second boot code block; 

(ii) determining the successful transfer of the upgraded 
boot code and the associated vector table to the second 
boot code block; 

(iii) causing the active boot code to overwrite a processor 
vector table stored in the memory with the associated 
upgraded vector table; and 

(iv) resetting the instrument upon verification that the 
overwriting of the processor vector table has occurred 
to thereby make the upgraded boot code the active boot 
code for the instrument after the resetting has occurred. 

DESCRIPTION OF THE DRAWING 

FIG. 1 shows a handheld terminal. 

FIG. 2 shows a simplified layout for the programmable 
memory in the handheld terminal. 

FIG. 3 is a block diagram showing the connection of the 
handheld terminal to a source of new boot code and/or main 
firmware. 

FIGS. 4A and 4B show a flowchart for the boot code and 
main firmware upgrade procedures. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENT^) 

Referring now to FIG. 1, there is shown an example of a 
remote handheld terminal 10 used in the process control 
industries. Terminal 10 includes a keypad 12 which includes 
keys that turn the terminal on and off as well as various keys 
that allow the technician to configure, monitor and trouble - 
shoot process control field devices. Terminal 10 further 
includes a display 14 and a cord 16. The cord 16 has clip 
leads (not shown) which are used to clip onto the signal 
wires of the field devices. 

Handheld terminal 10 further includes an RS232 port 18 
which may, be for example, be located in the bottom of 
terminal 10 as is shown in FIG. 1. Port 18 allows the 
handheld terminal 10 to be connected by a suitable cable to 
the serial port of a personal computer (PC) 32 [see FIG. 3] 
so that in accordance with the present invention the boot 
and/or main firmware in the terminal can be upgraded. 

Internal to the terminal 10 is a programmable memory 20, 
a simplified layout for which is shown in FIG. 2, and a 
microprocessor and associated electronics 30 (see FIG. 3). 
Memory 20 may for example be a Flash electrically erasable 
programmable read-only memory. As is shown in FIG. 2, the 
memory 20 is partitioned into functional software units 
where the boot code and main firmware reside. Specifically, 
in memory 20 there are first and second boot code units 22, 
24, main firmware unit 26, and process vector table 28. As 
will be described in more detail below, the first boot code 
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and second boot code are not simultaneously active. When 
the first boot code is active the second boot code is inactive 
and vice versa. 

Each of the boot code units 22, 24 include a copy of the 
vector table 22a, 24a at the top of each of units 22, 24. 
Directly below the vector table, each unit includes a version 
label 22b, 246 and directly below the version label each unit 
includes the boot code 22c, 24c. The main firmware unit 
includes at its top a checksum and version label 26a. 
Directly below the checksum and version label, the main 
firmware table includes a vector jump table 26b. 

The main firmware 26c is directly below the vector jump 
table. 

The upgrading of the boot code will first be described 
below followed by a description of the upgrading of the 
main firmware. When the boot code and/or main firmware in 
terminal 10 is to be upgraded, the RS232 port 18 of terminal 
10 is, as is shown in the block diagram of FIG. 3, connected 
to the serial port 36 of the PC 32 by cable 34. PC 32 includes 
the application software that communicates with the termi- 
nal 10 during the upgrade. 

When terminal 10 is operating, either boot code 1 or boot 
code 2, but not both, is active. The microprocessor 30 
operates under control of the then active boot code to 
perform the upgrade of the boot code and/or main firmware. 
In the boot code upgrade, the inactive boot code is replaced 
with upgraded, that is, new boot code from PC 32. When 
terminal 10 and thus microprocessor 30 is reset, the new 
boot code becomes the active boot code. In the main 
firmware upgrade, the main firmware then in terminal 10 is 
replaced with new main firmware from the PC 32. 

In both upgrades the files for the upgraded boot code 
firmware and the upgraded main firmware are made avail- 
able to a registered user of the handheld terminal 10 on an 
Internet web site. The registered user can log on to the web 
site and download the upgrade file(s) from the web site onto 
PC 32. The boot code and main firmware addresses are 
encrypted in the associated upgrade file so that PC 32 can 
control the addresses in memory 20 into which the upgraded 
boot code and/or main firmware are written. The files for the 
upgraded firmware that are posted on the web site may be 
encrypted for purposes of security and also contain the 
version number and checksum information. 
Boot Code Upgrade 

In the procedure for upgrading of the boot code, the new, 
that is, upgraded, boot code replaces the boot code in the 
inactive boot code block of terminal 10. For example, if boot 
code block 22 is active during the boot code upgrade then 
the new boot code will be written into boot code block 24. 
Upon the resetting of terminal 10 and thus microprocessor 
30, the new boot code will become the active boot code of 
the handheld terminal 10. 

The specific procedure for upgrading the boot code 
including swapping the upgraded boot code for the non- 
upgraded boot code is as follows: 

1. The PC application software sends a command to the 
terminal 10 to read the processor vector table 28 to 
thereby determine which one of the boot code blocks 
22, 24 is currently active in the terminal. For purposes 
of explanation it will be presumed hereinafter that boot 
code 22c is active in terminal 10. 

2. The PC then requests the handheld active boot code 22c 
to start tracking a checksum on the data, that is the new 
boot code, being written into the inactive block 24. The 
new code is then sent to the inactive boot code block 
24. 
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The new boot code can be written to a start address that 
is different than the start address of the inactive boot code. 
This flexibility allows boot code block 24 to be moved to 
accommodate an increase in the size of the new boot code 
now being written to block 24 or an increase in the size of 
boot code block 22 that is planned to appear in the next 
upgrade. It should be appreciated that the new boot code 
should not overwrite any part of the active boot code. The 
relocation of block 24 is taken into account when vector 
table copy 24a is written into the processor vector table 28 
at the end of the upgrade procedure. 

3. After the PC upgrades the inactive boot code block 24, 
the PC confirms the checksum of the newly loaded 
upgraded boot code 24. 

4. Upon confirmation of the checksum the PC sends a 
command to terminal 10 to indicate that the new boot 
code firmware was successfully transferred to boot 
code block 24. This command is also a request to the 
active boot code 22c to turn off all interrupt activity and 
copy the new vector table copy 24a transmitted from 
the PC into the processor vector table 28 and reset the 
handheld terminal 10. The vector table copy 24a of the 
new boot code 24c has to be transferred to the processor 
vector table 28 of memory 20 to make the new boot 
code 24c the active boot code of the terminal 10. 

5. In response to the command from the PC to transfer the 
new vector table copy 24a into the processor vector 
table 28, the terminal 10 shuts off all of its interrupts in 
order to make sure that none of the interrupt vectors are 
used. The terminal then overwrites the processor vector 
table 28 with the vector table copy 24a of the newly 
upgraded boot code 24c. 

6. Upon verification by the now active boot code 22c that 
the overwrite of processor vector table 28 has occurred, 
the boot code 22c resets the terminal 10. Upon terminal 
10 reset, the upgraded boot code 24c becomes the 
active boot code of the terminal. 

It should be appreciated that at the end of the successful 
upgrade of boot code block 24 described above, boot code 
24c of block 24, that is the new boot code, is the active boot 
code for the handheld terminal 10 and boot code 22c of 
block 22 is inactive as that is the old, that is, not upgraded, 
boot code. The next time the boot code is to be upgraded, it 
will be boot code 22c in inactive block 22 that is upgraded. 
At the successful end of that upgrade, the new boot code of 
boot code 22c of block 22 will become the active boot code 
for the terminal 10 and the old boot code of boot code 24c 
of block 24 will become the inactive boot code. Therefore, 
each successful upgrade of the boot code causes the previ- 
ously inactive boot code block to become the active boot 
code and the previously active boot code block to become 
the inactive boot code block. 
Main Firmware Upgrade 

The specific procedure for upgrading the main firmware is 
as follows: 

1. The PC application program sends commands to the 
terminal 10 to prepare the terminal for the upgrade. 
These commands request the active boot code to start 
checking a checksum on the data, for, the new, that is, 
upgraded main firmware to be written into the memory 
20. 

2. The PC transmits the new main firmware to terminal 
10. The new main firmware can be written to a start 
address which is different than the start address of the 
present main firmware. This flexibility allows the main 
firmware block 26 to be moved to accommodate an 
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increase in size of the main firmware now being written 
or a planned increase in the size of the next upgrade of 
the main firmware or the boot code. 

3. The PC confirms the checksum check at the end of the 
transfer to verify that the transfer was successful. 5 

4. Upon verification of a successful transfer, the PC will 
send a reset command to the terminal 10 so that the 
terminal can start running the new firmware. 

The interrupt vectors in the main firmware are double 
indexed through a fixed table. The processor vector table 28 
will point to a location in the main firmware vector jump 
table 26b which in turn points to a location in the main 
firmware 26c. Therefore, even if the main firmware vector 
jump table 26b is changed by the main firmware upgrade the 
double indexing avoids the need to upgrade the processor 
vector table 28 at the end of the main firmware upgrade. 

FIGS. 4Aand 4B show a flowchart for the boot code and 
main firmware upgrade procedures described above. 

As was described above, the boot code and main firmware 

. 20 

addresses are encrypted in the associated upgrade file so that 
the PC can control the addresses in memory 20 into which 
the upgraded boot code and/or main firmware are written. 
Therefore, the size and starting address of the boot code 
blocks 22, 24 and the main firmware block 26 in memory 20 
are not fixed and can be changed through the upgrade 
procedure. The only limitations on increasing the size of 
blocks 22, 24 and 26 are the size of memory 20 and the size 
of an adjacent block during the upgrade of blocks 22, 24 and 
26. For example, an increase in the size of main firmware 3Q 
block 26 through the upgrade procedure described above is 
limited by adjacent block 24. It should be appreciated that a 
series of upgrades can result in the increase of the size of 
block 26 by moving and/or shrinking blocks 22 and 24. 

Aboot code or main firmware upgrade procedure may fail ^ 
prior to completion for any one of a number of reasons 
including a power failure or a break in the cable 34 con- 
necting port 18 to the PC. Even if the procedure were to fail 
prior to completion, the terminal 10 is still operable. If the 
main firmware upgrade fails prior to completion the operator ^ 
can start terminal 10 again using the boot code firmware 
contained in memory 20 and reinitiate the main firmware 
upgrade. During a boot code firmware upgrade the boot code 
being upgraded is in the inactive boot code block. Therefore 
a failure in the upgrade prior to completion is not a problem 
as the terminal can still operate using the active boot code. 

The flexibility described above in writing new boot code 
or main firmware is also applicable where the new code is 
the same size as or less even than the code it is replacing. 

It is to be understood that the description of the preferred 
embodiment(s) is (are) intended to be only illustrative, 
rather than exhaustive, of the present invention. Those of 
ordinary skill will be able to make certain additions, 
deletions, and/or modifications to the embodiments) of the 
disclosed subject matter without departing from the spirit of ^ 
the invention or its scope, as defined by the appended claims. 

What is claimed is: 

1. A system for providing new boot code for a processor 
comprising: 

a. a writable non-volatile memory comprising: 60 

i. one region having active non-write protected boot 
code therein, said boot code having the functionality 
to allow an instrument containing said memory to 
communicate with a process control system; and 

ii. another region having therein an inactive non-write 65 
protected boot code which is a functional equivalent 

of said active boot code; 
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b. a source of said new boot code; and 

c. means including said processor and under control of 
said active boot code for replacing said inactive boot 
code with said new boot code from said source. 

2. The system of claim 1 wherein said memory further 
comprises a processor vector table and said new boot code 
includes a vector table, said replacing means causing after 
said new boot code has replaced said inactive boot code said 
new boot code vector table to be copied to said memory 
processor vector table so that said new boot code can 
become said active boot code upon resetting of said proces- 
sor. 

3. A system for providing new boot code for a processor 
comprising: 

a. a writable non-volatile memory comprising: 

i. one region having non-write protected active boot 
code therein, said boot code having the functionality 
to allow an instrument containing said memory to 
communicate with a process control system; and 

ii. another region having therein an inactive non-write 
protected boot code which is a functional equivalent 
of said active boot code; and 

b. a source of said new boot code connected to said 
processor; 

said processor operating under control of said active boot 
code for replacing said inactive boot code with said 
new boot code from said source. 

4. The system of claim 3 wherein said memory further 
comprises a processor vector table and said new boot code 
includes a vector table, said processor causing after said new 
boot code has replaced said inactive boot code said new boot 
code vector table to be copied to said memory processor 
vector table so that said new boot code can become said 
active boot code upon resetting of said processor. 

5. A method of providing new boot code for a processor, 
comprising the steps of: 

a. providing a writable non-volatile memory having one 
region having active non-write protected boot code for 
said processor therein, said boot code having the func- 
tionality to allow an instrument containing said 
memory to communicate with a process control system 
and another region having therein an inactive non-write 
protected boot code which is a functional equivalent of 
said active boot code; 

b. connecting a source of new boot code to said processor; 

c. transmitting said new boot code from said source to 
said processor; and 

d. writing under control of said active boot code said new 
boot code to said another region to thereby replace said 
inactive boot code. 

6. The method of claim 5 further including after said 
writing step the step of verifying that said new boot code is 
written to said another region. 

7. The method of claim 6 wherein said memory also has 
a processor vector table and said new boot code includes a 
vector table and said method further includes after said 
verifying step the step of copying said new boot code vector 
table to said memory processor vector table. 

8. The method of claim 7 further including after said 
copying step the step of resetting said processor so that said 
.new boot code becomes said active boot code. 

9. In a device having a processor a method of providing 
new boot code for said processor, comprising the steps of: 

a. providing in said device a writable non-volatile 
memory having one region having active non-write 
protected boot code for said processor therein, said 
boot code having the functionality to allow an instru- 
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ment containing said memory to communicate with a 
process control system and another region having 
therein an inactive non-write protected boot code which 
is a functional equivalent of said active boot code; 

b. connecting a source of new boot code to said processor; s 

c. transmitting said new boot code from said source to 
said processor; and 

d. writing under control of said active boot code said new 
boot code to said another region to thereby replace said 
inactive boot code. 10 

10. The method of claim 9 wherein said new boot code 
source is external to said device. 

11. The method of claim 9 further including after said 
writing step the step of verifying that said new boot code is 
written to said another region. 35 

12. The method of claim 11 wherein said memory also has 
a processor vector table and said new boot code includes a 
vector table and said method further includes after said 
verifying step the step of copying said new boot code vector 
table to said memory processor vector table. ^ 

13. The method of claim 12 further including after said 
copying step the step of resetting said processor so that said 
new boot code becomes said active boot code. 

14. A system for providing new boot code for a processor 

in a device, comprising: 25 

a. a writable non-volatile memory in said device, said 
memory comprising: 

i. one region having active non-write protected boot 
code therein, said boot code having the functionality 

to allow an instrument containing said memory to 3Q 
communicate with a process control system; and 

ii. another region having therein an inactive non-write 
protected boot code which is a functional equivalent 
of said active boot code; 

b. means for connecting a source of said new boot code 35 
to said device; and 

c. means including said processor and under control of 
said active boot code for replacing said inactive boot 
code with said new boot code from said source. 

15. The system of claim 14 wherein said device has a 40 
housing and said processor, said replacing means, and said 
memory are inside said housing. 

16. The system of claim 15 wherein said new boot code 
source is outside of said housing. 

17. The system of claim 15 wherein said source includes 45 
a connector and said means for connecting said source to 
said device comprises a connector on said housing and a 
cable compatible with said source connector and said hous- 
ing connector. 

18. A method for upgrading the boot code in an instrument 50 
having a non-volatile memory having a first boot code block 
having a vector table and a boot code area therein, and a 
second boot code block having a vector table and a boot 
code area therein, each of said first and said second boot 
code areas having non-write protected boot code therein, 55 
said method comprising the steps of: 

(a) determining from a processor vector table stored in 
said non- volatile memory which of said first and said 
second boot code blocks is then currently active, said 
boot code in said first boot code area having the 60 
functionality to allow said instrument to communicate 
with a process control system; 

(b) writing said upgraded boot code and an associated 
vector table into said boot code area and vector table 
area, respectively, of that one of said first and said 65 
second boot code blocks which is not then currently 
active; 



(c) determining the successful transfer of said upgraded 
boot code and said associated vector table to that one of 
said first and said second boot code blocks which is not 
then currently active; 

(d) causing said then currently active boot code to over- 
write said processor vector table with said vector table 
associated with said upgraded boot code; and 

(e) resetting said instrument upon verification that said 
overwriting of said processor vector table has occurred 
so that said upgraded boot code becomes the currently 
active boot code for said instrument after resetting has 
occurred. 

19. The method of claim 18 wherein in said writing step 
said upgraded boot code is written to a start address in said 
boot code area of that one of said first and said second boot 
code blocks which is not then currently active which is 
different than the start address of the boot code in said boot 
code area of that one of said first and said second boot code 
blocks which is then currently active. 

20. The method of claim 18 wherein said boot code in said 
first boot code block boot code area and said boot code in 
said second boot code block second area are functional 
equivalents of each other. 

21. The method of claim 18 wherein said step of deter- 
mining which of said first and said second boot code blocks 
is then currently active is preceded by the step of connecting 
said instrument to a processing device, said processing 
device obtaining said upgraded boot code from a remote 
source. 

22. A method for upgrading the boot code in an instrument 
having a non-volatile memory having a first boot code block 
having a vector table and a boot code area with currently 
active non-write protected boot code therein, and a second 
boot code block having a vector table and a boot code area 
with currently inactive non-write protected boot code 
therein, said currently active boot code having the function- 
ality to allow said instrument to communicate with a process 
control system, said method comprising the steps of: 

(a) writing said upgraded boot code and an associated 
vector table into said boot code area and vector table 
area, respectively, of said second boot code block; 

(b) determining the successful transfer of said upgraded 
boot code and said associated vector table to said 
second boot code block; 

(c) causing said then active boot code to overwrite a 
processor vector table stored in said memory with said 
associated upgraded vector table; and 

(d) resetting said instrument upon verification that said 
overwriting of said processor vector table has occurred 
to thereby make the upgraded boot code said active 
boot code for said instrument after said resetting has 
occurred. 

23. The method of claim 22 wherein in said writing step 
said upgraded boot code is written to a start address in said 
boot code area of said second boot code block which is 
different than the start address of said currently active boot 
code in said boot code area of said first block. 

24. The method of claim 22 wherein said currently active 
boot code and said currently inactive boot code are func- 
tional equivalents of each other. 

25. The method of claim 22 wherein said writing step is 
preceded by the step of connecting said instrument to a 
processing device, said processing device obtaining said 
upgraded boot code from a remote source. 

26. A method for operating an instrument having a non- 
volatile memory, said memory having a first boot code block 
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having a vector table and a boot code area with currently 
active non-write protected boot code therein, and a second 
boot code block having a vector table and a boot code area 
with currently inactive non-write protected boot code 
therein, said method comprising the steps of: 5 

(a) using said currently active boot code to operate said 
instrument, said currently active boot code having the 
functionality to allow said instrument to communicate 
with a process control system; and 

(b) upgrading said currently inactive boot code compris- 10 
ing the steps of: 

(i) writing said upgraded boot code and an associated 
vector table into said boot code area and vector table 
area, respectively, of said second boot code block; 

(ii) determining the successful transfer of said upgraded 15 
boot code and said associated vector table to said 
second boot code block; 

(iii) causing said active boot code to overwrite a 
processor vector table stored in said memory with 
said associated upgraded vector table; and 20 

(iv) resetting said instrument upon verification that said 
overwriting of said processor vector table has 
occurred to thereby make said upgraded boot code 
the active boot code for said instrument after said 
resetting has occurred. 25 

27. The method of claim 26 wherein in said writing step 
said upgraded boot code is written to a start address in said 
boot code area of said second boot code block which is 
different than the start address of said currently active boot 
code in said boot code area of said first block. 30 

28. The method of claim 26 wherein said currently active 
boot code and said currently inactive boot code are func- 
tional equivalents of each other. 

29. The method of claim 26 wherein said writing step is 
preceded by the step of connecting said instrument to a 
processing device, said processing device obtaining said 
upgrade boot code from a remote source. 

30. The method of claim 26 wherein said step of upgrad- 
ing said inactive boot code terminates prior to the comple- 
tion of said writing step and said instrument continues to 40 
operate using only said currently active boot code. 

31. A system for upgrading boot code in a nonvolatile 
memory of an instrument comprising: 

(a) a processing device having said upgraded boot code, <5 
said instrument connected to said processing device for 
receiving said upgraded boot code from said processing 
device; 

said instrument non-volatile memory comprising: 

(i) a first boot code block having a vector table and a 5Q 
boot code area with currently active non-write pro- 
tected boot code therein, said currently active boot 
code having the functionality to allow said instru- 
ment to communicate with a process control system; 

(ii) a second boot code block having a vector table and 55 
a boot code area with currently inactive non-write 
protected boot code therein; and 
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(iii) a processor vector table stored therein; 

said processing device causing said instrument to over- 
write said currently inactive boot code with said 
upgraded boot code and said vector table of said second 
boot code block with a vector table associated with said 
upgraded boot code, and said currently active boot code 
to overwrite said processor vector table with said 
associated upgraded vector table; 

said currently active boot code resetting said instrument 
when said overwriting of said processor vector table 
has occurred to thereby make said upgraded boot code 
the active boot code for said instrument after said 
resetting has occurred. 

32. The system of claim 31 wherein said processing 
device receives said upgraded boot code from a remote 
source. 

33. A method for upgrading boot code in a nonvolatile 
memory of an instrument, said memory having a first boot 
code block having a vector table and a boot code area with 
currently active non-write protected boot code therein, said 
currently active boot code having the functionality to allow 
said instrument to communicate with a process control 
system and a second boot code block having a vector table 
and a boot code area with currently inactive non-write 
protected boot code therein, said method comprising the 
steps of: 

(a) connecting said instrument to a processing device for 
receiving said upgraded boot code from said processing 
device; 

(b) upgrading said currently inactive boot code, said 
currently inactive boot code a functional equivalent of 
said currently active boot code, said upgrading com- 
prising the steps of: 

(i) writing said upgraded boot code and an associated 
vector table into said boot code area and vector table 
area, respectively, of said second boot code block; 

(ii) determining the successful transfer of said upgraded 
boot code and said associated vector table to said 
second boot code block; 

(iii) causing said active boot code to overwrite a 
processor vector table stored in said memory with 
said associated upgraded vector table; and 

(iv) resetting said instrument upon verification that said 
overwriting of said processor vector table has 
occurred to thereby make said upgraded boot code 
the active boot code for said instrument after said 
resetting has occurred. 

34. The method of claim 33 further comprising before 
said step of connecting said instrument to said processing 
device the step of connecting said processing device to a 
remote source for receiving said upgraded boot code from 
said remote source. 
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